Systems, methods, and apparatuses for implementing smart flow contracts using distributed ledger technologies in a cloud based computing environment

ABSTRACT

Systems, methods, and apparatuses for implementing smart flow contracts using distributed ledger technologies in a cloud based computing environment are described herein. For example, according to one embodiment there is a system having at least a processor and a memory therein executing within a host organization and having therein: means for operating a blockchain interface to a blockchain on behalf of a plurality of tenants of the host organization, wherein each of the plurality of tenants are participating nodes with the blockchain; means for receiving a login request from a user device; means for authenticating the user device with the host organization; means for receiving input from the user device indicating a plurality of smart contract blocks; means for translating each of the smart contract blocks into a native programming language to form a smart contract to execute via the blockchain; and means for transacting the smart contract onto the blockchain. Other related embodiments are disclosed.

CLAIM OF PRIORITY

None.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

TECHNICAL FIELD

Embodiments disclosed herein relate generally to the field ofdistributed ledger technology. More particularly, disclosed embodimentsrelate to systems, methods, and apparatuses for implementing intelligentconsensus, smart consensus, and weighted consensus models fordistributed ledger technologies in a cloud based computing environment.Other embodiments relate to systems, methods, and apparatuses forimplementing document interface and collaboration using Quipchain in acloud based computing environment. Still other embodiments relate tosystems, methods, and apparatuses for implementing super community andcommunity sidechains with consent management for distributed ledgertechnologies in a cloud based computing environment. Further embodimentsrelate to systems, methods, and apparatuses for implementing a virtualchain model for distributed ledger technologies in a cloud basedcomputing environment. Additional embodiments relate to systems,methods, and apparatuses for implementing smart flow contracts usingdistributed ledger technologies in a cloud based computing environment.Such embodiments may be implemented within the computing architecture ofa hosted computing environment, such as an on-demand or cloud computingenvironment which utilizes multi-tenant database technologies,client-server technologies, traditional database technologies, or othercomputing architecture in support of the hosted computing environment.

BACKGROUND

The subject matter discussed in the background section should not beconsidered prior art merely because of its mention in the backgroundsection. Similarly, a problem mentioned in the background section orassociated with the subject matter of the background section should notbe considered to have been previously recognized in the prior art. Thesubject matter in the background section merely represents differentapproaches, which in and of themselves, may also correspond to claimedembodiments.

In modern financial systems, assets such as currencies, or securities,are typically held and traded electronically. Transferring assets oftenrequires point-to-point interaction between multiple intermediaries, andreconciliation of duplicated ledgers. This system has somedisadvantages, such as the time required for settlement of assettransfers or payments, which often takes days, transfers involve feepayments to multiple intermediaries, and reconciliation can involveexpensive overhead, it may be difficult to find out the status of apending transfer or the current owner of an asset, transfers may notcomplete, and it may be difficult to make one transfer conditional onanother, the complexity of the such systems makes it difficult toprevent fraud or theft, and, whether transactions are reversible dependson the transfer mechanism, rather than the business requirements of thetransacting party.

Many of these problems can be fixed if asset ownership were recorded ona single shared ledger. However, a combination of practical andtechnological constraints have made such ledgers difficult to adopt.Such a shared ledger would tend to require trust in a single party. Thatparty would need to have the technical capacity to process everytransaction in real time. Additionally, to address the disadvantagesdiscussed above, the ledger would need to support more sophisticatedlogic than simple ownership changes. In 2009, a person or group ofpersons operating under the pseudonym Satoshi Nakamoto introducedBitcoin, the first implementation of a protocol that enables issuance ofa digital bearer instrument without a trusted third party, using anelectronic ledger replication system known as a blockchain. Bitcoinsolves the problem of implementing decentralized digital cash, but itssecurity model limits its efficiency and throughput, its design onlysupports a single asset, and its virtual machine has only limitedsupport for custom programs that determine asset movement, sometimescalled smart contracts.

Ethereum, introduced in 2015, generalizes the concept of a blockchain toa fully programmable state replication mechanism. While it includes amuch more powerful programming language, it presents additionalchallenges for scalability and efficiency.

In contrast to Bitcoin and Ethereum, which are designed to operate onthe public Internet, most financial activity already occurs withinrestricted networks of financial institutions. A shared ledger operatedwithin this network can take advantage of blockchain technology withoutsacrificing the efficiency, security, privacy, and flexibility needed byfinancial institutions.

The present state of the art may therefore benefit from the systems,methods, and apparatuses for improving upon, modifying, and expandingupon distributed ledger technologies and providing such capabilities viaan on-demand cloud based computing environment as is described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are illustrated by way of example, and not by way oflimitation, and will be more fully understood with reference to thefollowing detailed description when considered in connection with thefigures in which:

FIG. 1A depicts an exemplary architecture in accordance with describedembodiments;

FIG. 1B depicts another exemplary architecture, with additional detailof a blockchain protocol block 160, in accordance with describedembodiments;

FIG. 1C depicts another exemplary architecture, with additional detailof a blockchain and a forked blockchain, in accordance with describedembodiments;

FIG. 1D depicts another exemplary architecture with additional detailfor sidechains, in accordance with described embodiments;

FIG. 2 depicts a flow diagram illustrating a method for implementing adistributed ledger technology method, in accordance with describedembodiments;

FIG. 3 depicts a flow diagram illustrating a method for implementingintelligent consensus, smart consensus, and weighted consensus modelsfor distributed ledger technologies in a cloud based computingenvironment, in accordance with described embodiments;

FIG. 4 depicts a flow diagram illustrating a method for implementing adistributed ledger technology method, in accordance with describedembodiments;

FIG. 5 depicts a flow diagram illustrating a method for implementingdocument interface and collaboration using quipchain in a cloud basedcomputing environment, in accordance with described embodiments;

FIG. 6A depicts a flow diagram illustrating a method for implementing adistributed ledger technology method, in accordance with describedembodiments;

FIG. 6B depicts a flow diagram illustrating a method for implementing adistributed ledger technology method, in accordance with describedembodiments;

FIG. 7A depicts another exemplary architecture, with additional detailof a blockchain which implements community sidechains with consentmanagement, in accordance with described embodiments;

FIG. 7B depicts another exemplary architecture, with additional detailof a community sidechain with consent management, in accordance withdescribed embodiments;

FIG. 8A depicts another exemplary architecture, with additional detailof a blockchain which implements super community sidechains with consentmanagement, in accordance with described embodiments;

FIG. 8B depicts another exemplary architecture, with additional detailof GUI at a user device interacting with super community functionality,in accordance with described embodiments;

FIG. 8C depicts another exemplary architecture, with additional detailof GUI at a user device interacting with super community functionality,in accordance with described embodiments;

FIG. 9 depicts a flow diagram illustrating a method for implementingSuper community and community sidechains with consent management fordistributed ledger technologies in a cloud based computing environment,in accordance with described embodiments;

FIG. 10 shows a diagrammatic representation of a system within whichembodiments may operate, be installed, integrated, or configured, inaccordance with described embodiments;

FIG. 11A depicts another exemplary architecture, with additional detailof a blockchain implemented smart contract created utilizing a smartflowcontract engine, in accordance with described embodiments;

FIG. 11B depicts another exemplary architecture, with additional detailof a blockchain implemented smart contract created utilizing an Apextranslation engine, in accordance with described embodiments;

FIG. 12 depicts a flow diagram illustrating a method for implementingsmart flow contracts using distributed ledger technologies in a cloudbased computing environment, in accordance with described embodiments;

FIG. 13 shows a diagrammatic representation of a system within whichembodiments may operate, be installed, integrated, or configured, inaccordance with described embodiments;

FIG. 14 depicts another exemplary architecture, with additional detailof a virtual chain model utilized to interface with for distributedledger technologies via a cloud based computing environment, inaccordance with described embodiments;

FIG. 15 depicts a flow diagram illustrating a method for implementing avirtual chain model for distributed ledger technologies in a cloud basedcomputing environment, in accordance with described embodiments;

FIG. 16A illustrates a block diagram of an environment in which anon-demand database service may operate in accordance with the describedembodiments;

FIG. 16B illustrates another block diagram of an embodiment of elementsof FIG. 16A and various possible interconnections between such elementsin accordance with the described embodiments; and

FIG. 17 illustrates a diagrammatic representation of a machine in theexemplary form of a computer system, in accordance with one embodiment.

DETAILED DESCRIPTION

Described herein are systems, methods, and apparatuses for implementingdistributed ledger technology in a cloud based computing environment.

For instance, according to a particular embodiment, distributed ledgertechnology contemplates a distributed ledger technology host, or ablockchain platform host, in a peer-to-peer network, the host having atleast a processor and a memory therein, receiving a request to add a newblock to a blockchain, the new block comprising a plurality oftransactions, the request specifying one of a plurality of transactiontypes. The host selects one of a plurality of consensus protocols forvalidating the request to add the new block to the blockchain,responsive to the specified transaction type. The host then validatesthe request to add the new block to the blockchain when consensus isreached according to the selected consensus protocol. Finally, the hostadds the new block of the blockchain, responsive to the validation ofthe request to add the new block to the blockchain.

According to another embodiment, there is a distributed ledgertechnology platform host, having at least a processor and a memorytherein, in which the platform host is to receive a collaborativedocument or portion thereof from a collaborative document processingapplication, create a blockchain asset comprising the collaborativedocument or portion thereof, create a blockchain transaction comprisingthe blockchain asset and a blockchain asset identifier associated with afirst collaborator that signed the collaborative document, broadcast theblockchain transaction into circulation on a blockchain, receivevalidation of the blockchain transaction, responsive to broadcasting theblockchain transaction in the blockchain, and commit the validatedblockchain transaction in a block to the blockchain.

In the following description, numerous specific details are set forthsuch as examples of specific systems, languages, components, etc., inorder to provide a thorough understanding of the various embodiments. Itwill be apparent, however, to one skilled in the art that these specificdetails need not be employed to practice the embodiments disclosedherein. In other instances, well known materials or methods have notbeen described in detail in order to avoid unnecessarily obscuring thedisclosed embodiments.

In addition to various hardware components depicted in the figures anddescribed herein, embodiments further include various operationsdescribed below. The operations described in accordance with suchembodiments may be performed by hardware components or may be embodiedin machine-executable instructions, which may be used to cause ageneral-purpose or special-purpose processor programmed with theinstructions to perform the operations. Alternatively, the operationsmay be performed by a combination of hardware and software.

Embodiments also relate to an apparatus for performing the operationsdisclosed herein. This apparatus may be specially constructed for therequired purposes, or it may be a general purpose computer selectivelyactivated or reconfigured by a computer program stored in the computer.Such a computer program may be stored in a computer readable storagemedium, such as, but not limited to, any type of disk including opticaldisks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs),random access memories (RAMs), EPROMs, EEPROMs, magnetic or opticalcards, or any type of media suitable for storing electronicinstructions, each coupled to a computer system bus.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the required method steps. The required structurefor a variety of these systems will appear as set forth in thedescription below. In addition, embodiments are not described withreference to any particular programming language. It will be appreciatedthat a variety of programming languages may be used to implement theteachings of the embodiments as described herein.

Embodiments may be provided as a computer program product, or software,that may include a machine-readable medium having stored thereoninstructions, which may be used to program a computer system (or otherelectronic devices) to perform a process according to the disclosedembodiments. A machine-readable medium includes any mechanism forstoring or transmitting information in a form readable by a machine(e.g., a computer). For example, a machine-readable (e.g.,computer-readable) medium includes a machine (e.g., a computer) readablestorage medium (e.g., read only memory (“ROM”), random access memory(“RAM”), magnetic disk storage media, optical storage media, flashmemory devices, etc.), a machine (e.g., computer) readable transmissionmedium (electrical, optical, acoustical), etc.

Any of the disclosed embodiments may be used alone or together with oneanother in combination. Although various embodiments may have beenpartially motivated by deficiencies with conventional techniques andapproaches, some of which are described or alluded to within thespecification, the embodiments need not necessarily address or solve anyof these deficiencies, but rather, may address only some of thedeficiencies, address none of the deficiencies, or be directed towarddifferent deficiencies and problems which are not directly discussed.

FIG. 1A depicts an exemplary architecture 100 in accordance withdescribed embodiments.

In one embodiment, a hosted computing environment 111 is communicablyinterfaced with a plurality of user client devices 106A-C (e.g., such asmobile devices, smart phones, tablets, PCs, etc.) through hostorganization 110. In one embodiment, a database system 130 includesdatabases 155A and 155B, for example, to store application code, objectdata, tables, datasets, and underlying database records comprising userdata on behalf of customer organizations 105A-C (e.g., users of such adatabase system 130 or tenants of a multi-tenant database type databasesystem or the affiliated users of such a database system). Suchdatabases include various database system types including, for example,a relational database system 155A and a non-relational database system155B according to certain embodiments.

In certain embodiments, a client-server computing architecture may beutilized to supplement features, functionality, or computing resourcesfor the database system 130 or alternatively, a computing grid, or apool of work servers, or some combination of hosted computingarchitectures may provide some or all of computational workload andprocessing demanded of the host organization 110 in conjunction with thedatabase system 130.

The database system 130 depicted in the embodiment shown includes aplurality of underlying hardware, software, and logic elements 150 thatimplement database functionality and a code execution environment withinthe host organization 110.

In accordance with one embodiment, database system 130 utilizes theunderlying database system implementations 155A and 155B to servicedatabase queries and other data interactions with the database system130 that communicate with the database system 130 via the queryinterface. The hardware, software, and logic elements 150 of thedatabase system 130 are separate and distinct from the customerorganizations (105A, 105B, and 105C) which utilize web services andother service offerings as provided by the host organization 110 bycommunicably interfacing to the host organization 110 via network 155.In such a way, host organization 110 may implement on-demand services,on-demand database services or cloud computing services to subscribingcustomer organizations 105A-C.

Further depicted is the host organization 110 receiving input and otherrequests 115 from customer organizations 105A-C via network 155 (such asa public Internet). For example, incoming search queries, databasequeries, API requests, interactions with displayed graphical userinterfaces and displays at the user client devices 106A-C, or otherinputs may be received from the customer organizations 105A-C to beprocessed against the database system 130, or such queries may beconstructed from the inputs and other requests 115 for execution againstthe databases 155 or the query interface 180, pursuant to which results116 are then returned to an originator or requestor, such as a user ofone of a user client device 106A-C at a customer organization 105A-C.

In one embodiment, each customer organization 105A-C is an entityselected from the group consisting of: a separate and distinct remoteorganization, an organizational group within the host organization 110,a business partner of the host organization 110, or a customerorganization 105A-C that subscribes to cloud computing services providedby the host organization 110.

In one embodiment, requests 115 are received at, or submitted to, aweb-server 175 within host organization 110. Host organization 110 mayreceive a variety of requests for processing by the host organization110 and its database system 130. Incoming requests 115 received atweb-server 175 may specify which services from the host organization 110are to be provided, such as query requests, search request, statusrequests, database transactions, graphical user interface requests andinteractions, processing requests to retrieve, update, or store data onbehalf of one of the customer organizations 105A-C, code executionrequests, and so forth. Web-server 175 may be responsible for receivingrequests 115 from various customer organizations 105A-C via network 155on behalf of the query interface 180 and for providing a web-basedinterface or other graphical displays to an end-user user client device106A-C or machine originating such data requests 115.

The query interface 180 is capable of receiving and executing requestedqueries against the databases and storage components of the databasesystem 130 and returning a result set, response, or other requested datain furtherance of the methodologies described. The query interface 180additionally provides functionality to pass queries from web-server 175into the database system 130 for execution against the databases 155 forprocessing search queries, or into the other available data stores ofthe host organization's computing environment 111. In one embodiment,the query interface 180 implements an Application Programming Interface(API) through which queries may be executed against the databases 155 orthe other data stores.

Host organization 110 may implement a request interface 176 viaweb-server 175 or as a stand-alone interface to receive requests packetsor other requests 115 from the user client devices 106A-C. Requestinterface 176 further supports the return of response packets or otherreplies and responses 116 in an outgoing direction from hostorganization 110 to the user client devices 106A-C. Authenticator 140operates on behalf of the host organization to verify, authenticate, andotherwise credential users attempting to gain access to the hostorganization.

Further depicted within host organization 110 is the blockchain servicesinterface 190 having included therein both a blockchain consensusmanager 191 and a block validator 192. Blockchain services interface 190communicatively interfaces the host organization 110 with otherparticipating nodes 133 (e.g., via the network 155) so as to enable thehost organization 110 to participate in available blockchain protocolsby acting as a blockchain protocol compliant node so as to permit thehost organization 110 to access information within such a blockchain aswell as enabling the host organization 110 to provide blockchainservices to other participating nodes 133 for any number of blockchainprotocols supported by, and offered to customers and subscribers by thehost organization 110.

A blockchain is a continuously growing list of records, grouped inblocks, which are linked together and secured using cryptography. Eachblock typically contains a hash pointer as a link to a previous block, atimestamp and transaction data. By design, blockchains are inherentlyresistant to modification of the data. A blockchain system essentiallyis an open, distributed ledger that records transactions between twoparties in an efficient and verifiable manner, which is also immutableand permanent. A distributed ledger (also called a shared or commonledger, or referred to as distributed ledger technology (DLT)) is aconsensus of replicated, shared, and synchronized digital datageographically spread across multiple nodes. The nodes may be located indifferent sites, countries, institutions, user communities, customerorganizations, host organizations, hosted computing environments, orapplication servers. There is no central administrator or centralizeddata storage.

Blockchain systems use a peer-to-peer (P2P) network of nodes, andconsensus algorithms ensure replication of digital data across nodes. Ablockchain system can be either public or private. Not all distributedledgers necessarily employ a chain of blocks to successfully providesecure and valid achievement of distributed consensus: a blockchain isonly one type of data structure considered to be a distributed ledger.

P2P computing or networking is a distributed application architecturethat partitions tasks or workloads between peers. Peers are equallyprivileged, equally capable participants in an application that forms apeer-to-peer network of nodes. Peers make a portion of their resources,such as processing power, disk storage or network bandwidth, directlyavailable to other network participants, without the need for centralcoordination by servers or hosts. Peers are both suppliers and consumersof resources, in contrast to the traditional client-server model inwhich the consumption and supply of resources is divided. A peer-to-peernetwork is thus designed around the notion of equal peer nodessimultaneously functioning as both clients and servers to the othernodes on the network.

For use as a distributed ledger, a blockchain is typically managed by apeer-to-peer network collectively adhering to a protocol for validatingnew blocks. Once recorded, the data in any given block cannot be alteredretroactively without the alteration of all subsequent blocks, whichrequires collusion of the network majority. In this manner, blockchainsare secure by design and are an example of a distributed computingsystem with high Byzantine fault tolerance. Decentralized consensus hastherefore been achieved with a blockchain. This makes blockchainspotentially suitable for the recording of events, medical records,insurance records, and other records management activities, such asidentity management, transaction processing, documenting provenance, orvoting.

A blockchain database is managed autonomously using a peer-to-peernetwork and a distributed timestamping server. Records, in the form ofblocks, are authenticated in the blockchain by collaboration among thenodes, motivated by collective self-interests. As a result,participants' uncertainty regarding data security is minimized. The useof a blockchain removes the characteristic of reproducibility of adigital asset. It confirms that each unit of value, e.g., an asset, wastransferred only once, solving the problem of double spending.

Blocks in a blockchain each hold batches (“blocks”) of validtransactions that are hashed and encoded into a Merkle tree. Each blockincludes the hash of the prior block in the blockchain, linking the two.The linked blocks form a chain. This iterative process confirms theintegrity of the previous block, all the way back to the first block inthe chain, sometimes called a genesis block or a root block.

By storing data across its network, the blockchain eliminates the risksthat come with data being held centrally and controlled by a singleauthority. Although the host organization 110 provides a wide array ofdata processing and storage services, including the capability ofproviding vast amounts of data with a single responsible agent, such asthe host organization 110, blockchain services differ insomuch that thehost organization 110 is not a single authority for such services, butrather, via the blockchain services interface 190, is merely one of manynodes for an available blockchain protocol or operates as blockchainprotocol manager and provider, while other participating nodes 133communicating with the host organization 110 via blockchain servicesinterface 190 collectively operate as the repository for the informationstored within a blockchain by implementing compliant distributed ledgertechnology (DLT) in accordance with the available blockchain protocoloffered by the host organization 110.

The decentralized blockchain may use ad-hoc message passing anddistributed networking. The blockchain network lacks centralized pointsof vulnerability that computer hackers can exploit. Likewise, it has nocentral point of failure. Blockchain security methods include the use ofpublic-key cryptography. A public key is an address on the blockchain.Value tokens sent across the network are recorded as belonging to thataddress. A private key is like a password that gives its owner access totheir digital assets or the means to otherwise interact with the variouscapabilities that blockchains support. Data stored on the blockchain isgenerally considered incorruptible. This is where blockchain has itsadvantage. While centralized data is more controllable, information anddata manipulation are common. By decentralizing it, blockchain makesdata transparent to everyone involved.

Every participating node 133 for a particular blockchain protocol withina decentralized system has a copy of the blockchain for that specificblockchain protocol. Data quality is maintained by massive databasereplication and computational trust. No centralized official copy of thedatabase exists and, by default, no user and none of the participatingnodes 133 are trusted more than any other, although this default may bealtered via certain specialized blockchain protocols as will bedescribed in greater detail below. Blockchain transactions are broadcastto the network using software, via which any participating node 133,including the host organization 110 when operating as a node, receivessuch transaction broadcasts. Broadcast messages are delivered on a besteffort basis. Nodes validate transactions, add them to the block theyare building, and then broadcast the completed block to other nodes.Blockchains use various time-stamping schemes, such as proof-of-work, toserialize changes. Alternate consensus may be utilized in conjunctionwith the various blockchain protocols offered by and supported by thehost organization, with such consensus mechanisms including, for exampleproof-of-stake, proof-of-authority and proof-of-burn, to name a few.

Open blockchains are more user friendly than conventional traditionalownership records, which, while open to the public, still requirephysical access to view. Because most of the early blockchains werepermissionless, there is some debate about the specific accepteddefinition of a so called “blockchain,” such as, whether a privatesystem with verifiers tasked and authorized (permissioned) by a centralauthority should be considered a blockchain. Proponents of permissionedor private chains argue that the term blockchain may be applied to anydata structure that groups data into time-stamped blocks. Theseblockchains serve as a distributed version of multiversion concurrencycontrol (MVCC) in databases. Just as MVCC prevents two transactions fromconcurrently modifying a single object in a database, blockchainsprevent two transactions from spending the same single output in ablockchain. Regardless, of the semantics, the methodologies describedherein with respect to a “blockchain” expand upon conventionalblockchain protocol implementations to provide additional flexibility,open up new services and use cases for the described blockchainimplementations, and depending upon the particular blockchain protocoloffered or supported by the blockchain services interface 190 of thehost organization 110, both private and public mechanisms are describedherein and utilized as needed for different implementations supported bythe host organization 110.

An advantage to an open, permissionless, or public, blockchain networkis that guarding against bad actors is not required and no accesscontrol is needed. This means that applications can be added to thenetwork without the approval or trust of others, using the blockchain asa transport layer. Conversely, permissioned (e.g., private) blockchainsuse an access control layer to govern who has access to the network. Incontrast to public blockchain networks, validators on private blockchainnetworks are vetted, for example, by the network owner, or one or moremembers of a consortium. They rely on known nodes to validatetransactions. Permissioned blockchains also go by the name of“consortium” or “hybrid” blockchains. Today, many corporations are usingblockchain networks with private blockchains, or blockchain-baseddistributed ledgers, independent of a public blockchain system.

FIG. 1B depicts another exemplary architecture 101, with additionaldetail of a blockchain protocol block 160, in accordance with describedembodiments.

In particular, a blockchain protocol block 160 is depicted here to bevalidated by the block validator 192 of the host organization 110, withthe blockchain protocol block including addition detail of its varioussub-components, and certain optional elements which may be utilized inconjunction with the blockchain protocol block 160 depending on theparticular blockchain protocol being utilized via the blockchainservices interface 190.

In accordance with a particular embodiment, the blockchain protocolblock 160 depicted here defines a particular structure for how thefundamental blocks of any given blockchain protocol supported by thehost organization 110 is organized.

The prior hash 161 is the result of a non-reversible mathematicalcomputation using data from the prior block 159 as the input. The priorblock 159 in turn utilized data from the n previous block(s) 158 to formthe non-reversible mathematical computation forming the prior hash forthose respective blocks. For instance, according to one embodiment thenon-reversible mathematical computation utilized is a SHA256 hashfunction, although other hash functions may be utilized. According tosuch an embodiment, the hash function results in any change to data inthe prior block 159 or any of the n previous blocks 158 in the chain,causing an unpredictable change in the hash of those prior blocks, andconsequently, invalidating the present or current blockchain protocolblock 160. Prior hash 161 creates the link between blocks, chaining themtogether to form the current blockchain protocol block 160.

When the block validator 192 calculates the prior hash 161 for the priorblock 159, the hash must meet certain criteria defined by data stored asthe standard of proof 165. For instance, in one embodiment, thisstandard of proof 165 is a number that the calculated hash must be lessthan. Because the output of the hashing function is unpredictable, itcannot be known before the hash is calculated what input will result inan output that is less than the standard of proof 165. The nonce 162 isused to vary the data content of the block, allowing for a large numberof different outputs to be produced by the hash function in pursuit ofan output that meets the standard of proof 165, thus making itexceedingly computationally expensive (and therefore statisticallyimprobable) of producing a valid block with a nonce 162 that results ina hash value meeting the criteria of the standard of proof 165.

Payload hash 162 provides a hash of the data stored within the blockpayload 169 portion of the blockchain protocol block 160 and need notmeet any specific standard of proof 165. However, the payload hash isincluded as part of the input when the hash is calculated for thepurpose of storing as the prior hash 161 for the next or subsequentblock. Timestamp 164 indicates what time the blockchain protocol block160 was created within a certain range of error. According to certainblockchain protocol implementations provided via the blockchain servicesinterface 190, the distributed network of users (e.g., blockchainprotocol nodes) checks the timestamp 164 against their own known timeand will reject any block having a time stamp 164 which exceeds an errorthreshold, however, such functionality is optional and may be requiredby certain blockchain protocols and not utilized by others.

The blockchain protocol certification 166 defines the required sizeand/or data structure of the block payload 169 as well as certifyingcompliance with a particular blockchain protocol implementation, andthus, certifies the blockchain protocol block subscribes to, implements,and honors the particular requirements and configuration options for theindicated blockchain protocol. The blockchain protocol certification 166may also indicate a version of a given blockchain protocol and theblockchain protocol may permit limited backward and forwardcompatibility for blocks before nodes will begin to reject newblockchain protocol blocks for non-compliance.

Block type 167 is optional depending on the particular blockchainprotocol utilized. Where required for a specific blockchain protocolexposed via the blockchain services interface 190, a block type 167 mustbe indicated as being one of an enumerated list of permissible blocktypes 167 as will be described in greater detail below. Certainblockchain protocols use multiple different block types 167, all ofwhich may have varying payloads, but have a structure which is known apriori according to the blockchain protocol utilized, the declared blocktype 167, and the blockchain protocol certification 166 certifyingcompliance with such requirements. Non-compliance or an invalid blocktype or an unexpected structure or payload for a given declared blocktype 167 will result in the rejection of that block by network nodes.

Where a variable sized block payload 169 is utilized, the block type 167may indicate permissibility of such a variable sized block payload 169as well as indicate the index of the first byte in the block payload 169and the total size of the block payload 169. The block type 167 may beutilized store other information relevant to the reading, accessing, andcorrect processing and interpretation of the block payload 169.

Block payload 169 data stored within the block may relate to any numberof a wide array of transactional data depending on the particularimplementation and blockchain protocol utilized, including payloadinformation related to, for example, financial transactions, ownershipinformation, data access records, document versioning, medical records,voting records, compliance and certification, educational transcripts,purchase receipts, digital rights management records, or literally anykind of data that is storable via a payload of a blockchain protocolblock 160, which is essentially any data capable of being digitized.Depending on the particular blockchain protocol chosen, the payload sizemay be a fixed size or a variable size, which in either case, will beutilized as at least part of the input for the hash that produces thepayload hash 163.

Various standard of proofs 165 may utilized pursuant to the particularblockchain protocol chosen, such as proof of work, hash valuerequirements, proof of stake, a key, or some other indicator such as aconsensus, or proof of consensus. Where consensus based techniques areutilized, the blockchain consensus manager 191 provides consensusmanagement on behalf of the host organization 110, however, the hostorganization 110 may be operating only as one of many nodes for a givenblockchain protocol which is accessed by the host organization 110 viathe blockchain services interface 190 or alternatively, the hostorganization 110 may define and provide a particular blockchain protocolas a cloud based service to customers and subscribers (and potentiallyto non-authenticated public node participants), via the blockchainservices interface 190. Such a standard of proof 165 may be applied as arule that requires a hash value to be less than the proof standard, morethan the proof standard, or may require a specific bit sequence (such as10 zeros, or a defined binary sequence) or a required number of leadingor trailing zeroes (e.g., such as a hash of an input which results in 20leading or trailing zeros, which is computationally infeasible toprovide without a known valid input).

The hash algorithms used for the prior hash 161, the payload hash 163,or the authorized hashes 168 may be all of the same type or of differenttypes, depending on the particular blockchain protocol implementation.For instance, permissible hash functions include MD5, SHA-1, SHA-224,SHA-256, SHA-384, SHA-515, SHA-515/224, SHA-515/256, SHA-3 or anysuitable hash function resistant to pre-image attacks. There is also norequirement that a hash is computed only once. The results of a hashfunction may be reused as inputs into another or the same hash functionagain multiple times in order to produce a final result.

FIG. 1C depicts another exemplary architecture 102, with additionaldetail of a blockchain and a forked blockchain, in accordance withdescribed embodiments.

More particularly, there is now depicted a primary blockchain (e.g., aconsensus blockchain) which begins with a genesis block 141 (sometimescalled a root block) followed by a series of standard blocks 142, eachhaving a header which is formed based at least in part from a hash ofthe header of the block which precedes it. There is additionallydepicted a forked blockchain formed with an initial fork root block 144,followed by then a series of standard blocks 142. Because each block inthe blockchain contains a hash of the immediately preceding block storedin the previous hash, a link going back through the chain from eachblock is effectively created via the blockchain and is a key componentto making it prohibitively difficult or computationally infeasible tomaliciously modify the chain.

As depicted, the primary blockchain includes a single fork which isoriginating from the fork block 143. As shown here, the genesis block141 is a special block that begins the primary blockchain and isdifferent from the other blocks because it is the first block in theprimary block chain and therefore, cannot by definition, include a hashof any previous block. The genesis block 141 marks the beginning of theprimary blockchain for the particular blockchain protocol beingutilized. The blockchain protocol governs the manner by which theprimary blockchain grows, what data may be stored within, and forkedblockchains are created, as well as the validity of any block and anychain may be verified via the block validator 192 of the hostorganization or any other participating network node of the blockchainpursuant to the rules and requirements set forth by the blockchainprotocol certification 166 which is embedded within the genesis block141 and then must be certified to and complied with by every subsequentblock in the primary blockchain or any forked blockchain.

The blockchain protocol certification 166 inside each block in thegenesis chain defines the default set of rules and configurationparameters that allows for the creation of forks and the modification ofrules and configuration parameters in those forks, if any. Someblockchain protocol implementations permit no variation ornon-compliance with the default set of rules as established via theblockchain protocol certification 166 and therefore, any fork will bethe result of pending consensus for multiple competing potentially validprimary blockchains. Once consensus is reached (typically after one ortwo cycles and new block formations) then the branch having consensuswill be adopted and the fork truncated, thus returning to a singleprimary consensus blockchain. Conversely, in other implementations, aforked blockchain may permissibly be created and continue to existindefinitely alongside the primary blockchain, so long as the forkedblockchain complies with the blockchain protocol certification 166 andpermissible variation of rules and configuration parameters for a forkedblockchain within that blockchain protocol.

Fork block 143 anchors the forked blockchain to the primary blockchainsuch that both the primary blockchain and the forked chain areconsidered valid and permissible chains where allowed pursuant to theblockchain protocol certification 166. Normally, in a blockchain, allnon-consensus forks are eventually ignored or truncated and thusconsidered invalid except for the one chain representing the longestchain having consensus. Nevertheless, the fork block 143 expands beyondthe conventional norms of prior blockchain protocols by operating as andappearing as though it is a standard block 142, while additionallyincluding a reference to a fork hash 149 identifying the first block ofthe permissible forked blockchain, represented here as the fork rootblock 144 for the valid forked blockchain. The fork root block 144 ofthe forked blockchain is then followed by standard blocks, each having aheader based on a prior valid block's hash, and will continueindefinitely.

According to a particular embodiment, the forked blockchain utilizessome variation from the rules and configuration parameters utilized bydefault within the primary consensus blockchain, resulting in the needfor a valid forked blockchain. Therefore, the variation of the rules andconfiguration parameters are encoded within a new blockchain protocolcertification 166 for the fork root block 144 which, as noted above,must remain compliant with the original rules and valid range ofconfiguration parameters as set forth by the blockchain protocolcertification 166 of the original genesis block 141 for the primaryblockchain. Because the fork root block 144 must continue to carry theoriginal blockchain protocol certification 166, a forked blockchainprotocol certification may be stored within a block payload 169 segmentof the fork root block 144 thus establishing the rules and permissibleconfiguration parameters of subsequent standard blocks 142 in the forkedblockchain.

When a new blockchain protocol certification 166 is applied for a validfork, its rules and configuration is applied to all subsequent standardblocks for the fork and all subsequent sub-forks, where additional forksare permitted, and enforced by the participating nodes as though theforked blockchain were an original primary blockchain. Such forks may bedesirable for certain customers seeking to apply a specialized set ofrules or configurations for a particular group, such as a working group,a certain sub-type of transactions, or some other variation from theprimary blockchain where an entirely separate “sidechain” is notrequired or desirable. A forked blockchain is distinguishable from asidechain as it remains part of the same blockchain protocol and ispermanently connected with the primary blockchain at the fork block 143with a returned fork hash 149 being returned to and immutably writteninto the primary consensus blockchain where it will remain via the chainhashing scheme for all subsequent standard blocks of the primaryblockchain. Stated very simply, the forked blockchain is explicitly tiedto the primary blockchain via the fork block 143. Conversely, asidechain may be an entirely distinct blockchain protocol for which anagreed rate of exchange or conversion factor is applied to allinformation or value passed between the primary blockchain and anysidechain without any explicit reference or fork hash 149 embeddedwithin the primary blockchain.

Sidechaining therefore is a mechanism by which tokens, value, or payloadentries from one blockchain may be securely used within a completelyseparate blockchain via a pre-defined exchange or conversion scheme, andyet, be permissibly moved back to the original chain, if necessary. Byconvention the original blockchain is referred to as the main chain orthe primary blockchain, whereas any additional blockchains which allowusers to transact within them utilizing the tokens, values, or payloadof the main chain are referred to as sidechains. For instance, there maybe a private blockchain with a defined linkage to a public blockchain,thus allowing tokens, value, or payload data to be securely movedbetween the public blockchain and the private blockchain.

According to described embodiments, the blockchain protocolcertification 166 defining the protocol rules for a forked chain may bedeveloped in any relevant programming or scripting language, such as,Python, Ruby, Perl, JavaScript, PHP, Scheme, VBScript, Java, Microsoft.Net, C++, C#, C, or a custom-created language for defining the protocolrules.

Under normal operating conditions, even conventional blockchainsnaturally fork from time to time, however, with previously knownblockchains, ultimately only a single branch may form the primaryconsensus chain and all other forks must be ignored or truncated withonly the primary consensus blockchain being considered as valid.Consensus on which chain is valid may be achieved by choosing thelongest chain, which thus represents the blockchain having the most workput into completing it. Therefore, it is necessary to utilize the forkblock 143 as described herein to permit permissibly forked chains to becreated and certified as authorized forks via the fork hash 149 so as toprevent participating nodes to ignore or truncate the fork. Because eachnode may independently validate the forked blockchain, it will not beignored, just as a validated primary blockchain will not be ignored uponhaving consensus.

FIG. 1D depicts another exemplary architecture 103 with additionaldetail for sidechains, in accordance with described embodiments.

More particularly, there is depicted here mechanism by which to performa symmetric two-way pegged transfer from a parent blockchain 188 (e.g.,e.g., a primary chain) to a sidechain 189, which may be a differentblockchain protocol supported by and provided by the host organization110 or the sidechain may be a foreign blockchain, public or private, forwhich the sidechain exchange manager 193 of the host organization 110participates as a node, so as to permit access and transactionalcapabilities with the sidechain. Regardless, it is in accordance withdescribed embodiments that inter-chain transfers between the parentblockchain 188 and the sidechain 189 may permissibly performed incompliance with the rules and conditions of each respective blockchain.Notably, as described here, the perspective of each blockchain isinterchangeable insomuch that the sidechain 189 depicted here mayconsider itself as a primary or parent blockchain and consider thedepicted parent blockchain 188 as the child blockchain or a sidechain.Regardless, each blockchain operates independently, yet has a definedexchange mechanism by which to exchange tokens, value, or other payloadinformation between them.

As shown here, the sidechain exchange manager 193 of the hostorganization may send a parent chain asset as an output of the parentblockchain 188 at operation 151.

A Simplified Payment Verification (SPV) proof 181 associated with theparent blockchain 188 asset is generated as the output and communicatedto the sidechain 189. The SPV proof may include a threshold level ofwork, and the generating may take place over a predetermined period oftime, which may also be referred to as a confirmation period 152. Theconfirmation period of a transfer between chains may be a duration forwhich a coin, token, or other exchanged value is locked on the parentblockchain 188 before may successfully be transferred to the sidechain189. This confirmation period may allow for sufficient work to becreated such that a denial of service attack in the next waiting periodbecomes more computationally difficult.

Consider for instance an exemplary confirmation period which may be onthe order of 1-2 days. The confirmation period may be implemented, insuch an example, as a per-sidechain security parameter, which trades offcross-chain transfer speeds in exchange for greater security. Otherconfirmation periods which are much shorter may be utilized wheresufficiently difficult proof of work conditions are effectuated so as toensure adequate security so as to protect the integrity of bothblockchains and negate the potential for fraudulent transactions.

The output created on the parent blockchain 188 may specify via rulesand configuration parameters (e.g., stored within the blockchainprotocol certification portion of each block of the parent blockchain188) a requirement that any spending, transfer, or consumption of anasset received by the output in the future are burdened with additionalconditions, in addition to the rules governing transfer within theparent chain. For example, any release of assets received by the outputmay require additional conditions for verifying a proof from thedestination chain, such as validating that the rules for the destinationchain proof show that the destination chain has released the asset andshow to where the asset has been released. After creating the output onthe parent blockchain 188, the user waits out the confirmation period,meanwhile, intra-chain transfers 153 continue to occur. Subsequent towaiting out the confirmation period, a transaction is then created onthe sidechain 189 referencing the output from the parent blockchain 188.

The sidechain, using a sidechain validator service, such as the blockvalidator 192 of the host organization, is then provided with an SPVproof that shows the parent chain asset was created and encumbered bysufficient work within the parent chain. A sidechain validator service(e.g., block validator 192 if performed by the host organization'savailable services) will then validate that the SPV proof associatedwith the parent blockchain 188 asset meets the required threshold levelof work indicated by the SPV proof at operation 154 and a sidechain 189asset corresponding to the parent blockchain 188 asset is thengenerated.

The generated sidechain 189 asset also may be held for a predeterminedcontest period at operation 154, during which time the transfer will beinvalidated if a reorganization proof 183 associated with the parentblockchain 188 asset is detected in the parent blockchain.

The contest period at operation 154 may be a duration during which anewly-transferred token, coin, value, or payload data may not be spent,accessed, or consumed on the sidechain 189. The predetermined contestperiod is implemented to prevent any possibility for double-spending inthe parent blockchain 188 by transferring previously-locked coins,tokens, value, or payload data during a reorganization. If at any pointduring this delay, a new SPV proof 184 (known as a “reorganizationproof”) is published containing a chain with more aggregate work whichdoes not include the block in which the lock output was created, theconversion is retroactively invalidated. If no reorganization proof isdetected, the sidechain asset may be released. All participating nodeson the sidechain have an incentive to produce reorganization proofs ifpossible, as the consequence of a bad proof being admitted degrades thevalue of all sidechain tokens, coins, value, or trust in theauthenticity of payload data stored by the sidechain 189.

Similar to the above, an exemplary contest period at operation 156 mayalso be on the order of 1-2 days. To avoid these delays, users mayinstead employ use atomic swaps for fungible transfers, so long as aliquid market is available. Where the exchanged asset is a unique orless common token, value, or payload data, atomic swaps will not befeasible and a sidechain transfer must instead occur, despite thenecessity of a potentially lengthy 1-2 day waiting period.

Upon eventual release of the sidechain asset, the side chain assetcorresponding to the parent chain asset may then be transferred orconsumed within the sidechain one or more times the intra-chaintransfers 153 of the sidechain 189. While locked on the parentblockchain 188, the asset is freely transferable within the sidechainand without requiring any further interaction with the parent blockchain188, thus permitting the sidechain 189 to again operate whollyindependently. Notwithstanding the above, the sidechain asset retainsits identity as a parent chain token, coin, value, or payload data andmay therefore, if the need arises, be transferred back to theoriginating parent blockchain 188 from which the sidechain assetoriginated. In certain embodiments, transfers are relegated to only asingle hop, such that an asset cannot be transferred to a sidechain 189and then transferred again to another sidechain, where it is necessaryto prevent obfuscation of the source. Such restrictions are dependentupon the particular blockchain protocol chosen and the define exchangeagreement (e.g., pegging conditions) established between a parentblockchain 188 and a sidechain 189.

Where it becomes necessary to redeem a sidechain asset in the parentblockchain 188, the sidechain asset may be sent to an output of thesidechain as depicted at operation 157. An SPV proof 182 associated withthe sidechain asset is thus generated and communicated to the parentblockchain 188. A parent chain validator service, such as the blockvalidator 193 of the host organization 110, may validate the SPV proof182 associated with the sidechain asset at operation 156. The validatedthe SPV proof 182 associated with the sidechain 189 asset may include,for example, validation that the SPV proof 182 associated with thesidechain asset meets the threshold level of work indicated by the SPVproof 182 associated with the sidechain asset.

As before, the parent chain asset associated with the sidechain assetmay be held for a second predetermined contest period at step 156,during which a release of the parent chain asset is denied at operation158 if a reorganization proof 183 associated with the sidechain asset isdetected in the sidechain. The parent chain asset may be released if noreorganization proof 183 associated with the sidechain asset isdetected.

If validation failure occurs with respect to the second SPV proof 184,after the reorganization proof 183 is received, then a second SPV proof184 associated with the sidechain asset may be received and validated bythe parent blockchain 188 during a third predetermined contest period atoperation 159. The parent blockchain 188 asset may be released if noreorganization proof associated with the sidechain asset is detectedduring the third predetermined contest period, after which the parentchain asset is free to be transferred within the parent chain via thedepicted intra-chain transfers 153 shown at the rightmost side of theparent blockchain 188 flow.

Because pegged sidechains may carry assets from many differentblockchains, it may be problematic to make assumptions about thesecurity of the other foreign blockchains. It is therefore required inaccordance with certain embodiments that different assets are notinterchangeable (except by an explicit trade) within the sidechain.Otherwise, a malicious user may potentially execute a fraudulenttransaction by creating a worthless chain with a worthless asset, andthen proceed to move the worthless asset from their worthless chain intothe primary blockchain 188 or into a sidechain 189 with which theprimary blockchain 188 interacts and conducts exchanges. This presumesthat the worthless chain secures a pegged exchange agreement with thesidechain. However, because the rules, configuration options, andsecurity scheme of the sidechain 189 is not controlled by the parentblockchain 188 (assuming the sidechain is a foreign sidechain and notanother blockchain protocol provided by the host organization 110), itsimply cannot be known with certainty that the sidechain 189 beinginteracted with does not contain such vulnerabilities. To negate thispotential security vulnerability, the sidechain 189 may be required, asper the pegged exchange agreement, to treat assets from separate parentblockchains as wholly as separate asset types, as denoted by the blocktype portion of a blockchain protocol block as depicted at FIG. 1B,element 167.

With a symmetric two-way pegged sidechain transfer, both the parentblockchain 188 and sidechains 189 may perform SPV validation services ofdata on each other, especially where the parent blockchain 188 isprovided the host organization and where the sidechain is a foreignsidechain for which the host organization is merely a participating nodevia the sidechain exchange manager node 193. Because the parentblockchain 188 clients (e.g., participating nodes) do not observe everysidechain, users import proofs of work from the sidechain into theparent chain in order to prove possession. In a symmetric two-way peg,the reverse is also true. For example, to use Bitcoin as a parentblockchain 188, an extension script to recognize and validate such SPVproofs may be utilized. To facilitate such transactions, the SPV proofsshould be sufficiently small in size so as to fit within a Bitcointransaction payload. However, such a change may alternatively beimplemented as a forking transaction, as described previously, withoutaffecting transactions not involved in pegged sidechain transactions.Stated differently, using symmetric two-way pegged sidechains asdescribed above, no further restrictions would necessarily be placedupon any transaction deemed valid within Bitcoin.

Through the use of such pegged sidechains transactions, independentblockchains are made to be flexible enough to support many assets,including assets that did not exist when the chain was first created.Each of these assets may be labeled with the blockchain from which itwas transferred so as to ensure that transfers can be unwound (e.g.,transferred back) correctly.

According to certain embodiments, the duration of the contest periodcould be made as a function of the relative hashpower of the parentchain and the sidechain, such that the receiving sidechain (or theparent blockchain with an incoming transfer) may only unlock tokens,coins, value, or data payloads, given an SPV proof of one day's worth ofits own proof-of-work, which may, for example, correspond to severaldays of the sending blockchain's proof-of-work. Security parameters ofthe particular sidechain's blockchain protocol implementation may thusbe tuned to each particular sidechain's implementation.

FIGS. 2-4 depicts a flow diagram illustrating methods for implementingdistributed ledger technology in embodiments of the invention. In theembodiments, a hosted blockchain platform is provided based on one ormore blockchain framework implementations, including tools for buildingblockchain business networks and blockchain based applications. Thehosted blockchain platform may provide Blockchain as a Service (BaaS) tocustomers of a cloud based computing environment service provider, suchas the assignee of the present patent application, so that the customersdo not have to configure and set up a working blockchain and consensusmodels, including the attendant hardware and software. The describedmethods may be performed by processing logic that may include hardware(e.g., circuitry, dedicated logic, programmable logic, microcode, etc.),software (e.g., instructions run on a processing device) to performvarious operations such as designing, defining, retrieving, parsing,persisting, exposing, loading, executing, operating, receiving,generating, storing, maintaining, creating, returning, presenting,interfacing, communicating, transmitting, querying, processing,providing, determining, triggering, displaying, updating, sending, etc.,in pursuance of the systems and methods as described herein. Forexample, the hosted computing environment 111, its database system 130as depicted at FIG. 1A, et seq., and other systems and components asdescribed herein may implement the described methodologies. Some of thelogic blocks and/or operations listed below are optional in accordancewith certain embodiments. The numbering of the logic blocks presented isfor the sake of clarity and is not intended to prescribe an order ofoperations in which the various logic blocks must occur.

Some embodiments of the invention may operate in connection with apermissioned, or private, blockchain-based distributed ledgertechnology. In one embodiment, a consortium of nodes participate in thepermissioned blockchain, wherein each node is operated on or by adifferent party in the consortium. For example, the consortium mightinclude some number of banking or financing institutions, or insurancecompanies. In any case, the consortium members each communicate viatheir respective node with other members of the consortium to add and/orverify assets and/or transactions involving the assets to thepermissioned blockchain.

In one embodiment, the nodes have access to a data store, such as adatabase, an on-demand database service, or a distributed databasesystem, that maintains information about the types of assets and/ortransactions that may be committed to the permissioned blockchain,herein below sometimes referred to as the transaction type database. Inaddition, the data store associates a consensus protocol or consensusprotocol type with each transaction type. In one embodiment, one or morenodes maintains the database, while other nodes merely have read accessto the database. In other embodiment, a blockchain-based distributedledger platform host executing on, for example, an application server orcluster of application servers in a cloud computing service provider'scloud computing system, may set up and maintain the database, forexample, as part of a Blockchain-as-a-Service (BaaS) applicationsupported by the cloud computing service provider. In such anembodiment, the database is accessible to the application server(s), andthe nodes in the consortium access the database by sending requests to,and receiving responses from, the blockchain platform host. In oneembodiment, one or more nodes in the consortium, each represented withinor as a customer organization or community of the cloud computingservice, may access the database as subscribers of the cloud computingservice. In some embodiments, the information in the database may becached by the blockchain platform host, an application server, or acluster of application servers in a cloud computing service provider'scloud computing system, for ready read-access by or on behalf of nodesin the cloud computing environment.

When a block containing a particular asset or transaction is to be addedto the blockchain, the transaction type database is queried using thetype of the particular asset or transaction that is to be added to theblockchain to determine the corresponding consensus protocol type thatis to be used to commit the particular asset or transaction, or blockcontaining the particular asset or transaction, to the blockchain. Forexample, in the database, a transaction type of “loan” may be associatedwith a consensus protocol type of “proof of stake” (PoS), an asset typeof “document” may be associated with a consensus protocol type of“Byzantine Fault Tolerant” (BFT), an asset or transaction type of“currency” may be associated with a consensus protocol type of “proof ofwork” (PoW), and a default transaction type to be used in the case of anotherwise unenumerated transaction type in the database may beassociated with a default consensus protocol type, say, PoS.

Thus, continuing on with the example provided above, when a block ortransaction therein with a particular transaction having the type “loan”is to be added to the blockchain, the consensus protocol type to be usedto commit the block or transaction therein to the blockchain is PoS,when a block or transaction therein with a particular asset having thetype “document” is to be added to the blockchain, the consensus protocoltype to be used to commit the block or transaction therein to theblockchain is BFT, and when a block or transaction therein with aparticular transaction having a transaction type that is not specifiedin the database is to be added to the blockchain, then the defaultconsensus protocol type of PoS is to be used to commit the block ortransaction therein to the blockchain.

FIG. 2 depicts a flow diagram illustrating a method 200 for implementinga distributed ledger technology method, in accordance with describedembodiments.

With reference to FIG. 2, at block 205, processing logic of adistributed ledger technology (DLT) platform host, e.g., ablockchain-based DLT platform host, or simply, a blockchain platformhost, receives a request to add a new block to a blockchain. The newblock typically includes a number of transactions. The request specifiesa transaction type, or if no transaction type is specified, a defaulttransaction type is assumed or applied.

In one embodiment, the request is received from one of the nodes in apeer-to-peer network that make up a consortium. In one embodiment thetransaction type is specified in a blockchain protocol packettransmitted by the node. In one embodiment, the transaction type isspecified in an application specific data field in a payload portion ofthe blockchain protocol data packet, in which case, the blockchainprotocol itself is unaware of the transaction type being specified, andit is up to logic executing on the blockchain platform host to detectand decode the transaction type in the payload portion of the packet. Inanother embodiment, the transaction type is specified in a field in aheader portion of the blockchain protocol data packet, in which case,the blockchain protocol itself is aware of the transaction type beingspecified.

At logic block 210, the host obtains the transaction type from therequest, queries the transaction type database and returns acorresponding consensus protocol type to use in committing the block ortransaction therein to the blockchain. In particular, the host searchesthe database for the specified transaction type, and having found thespecified transaction type in a record in the database, obtains theselected consensus protocol associated with the specified transactiontype from the record. This selected consensus protocol type is thencommunicated to the nodes in the consortium for use in for validatingthe request to add the new block or transaction therein to theblockchain. At logic block 215, the host validates, or receivesvalidation of, the request to add the new block or transaction thereinto the blockchain when the nodes in the consortium reach consensusaccording to the selected consensus protocol to add the block ortransaction therein to the blockchain and communicate such to the host.Finally, at logic block 220 the host adds the validated new block ortransaction therein to the blockchain.

FIG. 3 depicts a flow diagram illustrating a method 300 for implementingintelligent consensus, smart consensus, and weighted consensus modelsfor distributed ledger technologies in a cloud based computingenvironment, which may operate in conjunction with the operations of theother flow diagrams as set forth herein.

According to another embodiment of the invention depicted at 300 in FIG.3, at block 305, processing logic for a distributed ledger technology(DLT) platform host receives a request to add a new block or transactiontherein to a blockchain. The new block typically includes a number oftransactions. The request specifies a transaction type, or if notransaction type is specified, a default transaction type is assumed orapplied.

In one embodiment, the request is received from one of the nodes in apeer-to-peer network that make up a consortium. In one embodiment thetransaction type is specified in a blockchain protocol packettransmitted by the node. In this embodiment, the transaction type mayspecified in an application specific data field in a payload portion ofthe blockchain protocol data packet or in a field in a header portion ofthe blockchain protocol data packet. In either case, at logic block 310,the host obtains the transaction type from the request, and engages amachine learning-based software agent to select one of a number ofconsensus protocol types to use in committing the block or transactiontherein to the blockchain based on the specified transaction type. Thismachine learning-based software agent may be built into the blockhainplatform, blockchain platform host, cloud computing environmentplatform, an application server or cluster of servers in a cloudcomputing services platform, for example, as a layer of artificialintelligence that delivers predictions and recommendations based onvarious selected factors, such as business processes and consortiumdata. This layer of artificial intelligence may use insights to automateselection of one of a number of consensus protocol types to use incommitting the block or transaction therein to the blockchain based onthe specified transaction type. In one embodiment, this layer ofartificial intelligence may be provided by Salesforce.com's Einstein, anartificial intelligence (AI) layer embedded in Salesforce's cloudcomputing services architecture.

In one embodiment, the machine learning-based software agent is areinforcement learning-based software agent, and it selects the one ofthe number of consensus protocols to use for validating the request toadd the new block or transaction therein to the blockchain based on oneor more factors, such as the specified transaction type, or a consensusprotocol selected for validating one or more previous requests to add anew block or transaction therein to the blockchain that specify the sametransaction type.

The selected consensus protocol type is communicated to the nodes in theconsortium for use in for validating the request to add the new block ortransaction therein to the blockchain. In particular, in one embodiment,the distributed ledger technology platform host transmits a blockchainprotocol packet consisting of an application specific data field in apayload portion of the blockchain protocol data packet that providesthis information. In another embodiment, a field in a header portion ofthe blockchain protocol data packet may specify the selected consensusprotocol. At logic block 315, the host validates, or receives validationof, the request to add the new block or transaction therein to theblockchain when participating nodes in the consortium reach consensusaccording to the selected consensus protocol to add the block ortransaction therein to the blockchain and communicate such to the host.In other words, not all nodes in the consortium necessarily participatein consensus protocol. To that end, logic block 311 optionally selectswhich nodes in the peer-to-peer network are to participate in theselected consensus protocol before the host validates, at logic block315, the request to add the new block or transaction therein to theblockchain based on learning that participating nodes in the consortiumhave reached consensus according to the selected consensus protocol toadd the block or transaction therein to the blockchain. Finally, atlogic block 320 the host adds the validated new block or transactiontherein to the blockchain.

In one embodiment, selecting the nodes in the peer-to-peer network toparticipate in the selected consensus protocol may be accomplished bylogic block 311 according to a rule-based set of factors, pre-definedand configured for example by the blockchain platform administrator,and/or by engaging a machine learning-based software agent that operateson the fly and over time, for example, a reinforcement learning-basedsoftware agent that automates consideration of some or all of the samerule-based factors in determining which nodes are to participate in theselected consensus protocol. Any relevant factors may be used indetermining which nodes participate in the consensus protocol,including, for example, the selected consensus protocol itself, aparticular node's computing resources, the stake a particular node hasin the consortium or the selected consensus protocol, relevant (domain)knowledge a particular node has, whether that knowledge is inside(on-chain) or outside (off-chain) with regard to the blockchain orconsortium, a particular node's previous or historical performance,whether in terms of speed or accuracy, or lack thereof, in participatingin the selected consensus protocol, the block number of the new blockbeing added to the blockchain, the number of transactions in the newblock, the size of the block, and the fiduciary or nonfiduciary natureof the assets or transactions in the block being added to theblockchain. Many of the above-mentioned factors could be consideredconcurrently, sequentially, hierarchically, or iteratively, in selectingwhich nodes participate in the selected consensus protocol.

Information about these factors may be communicated by and between thenodes and the blockchain platform host either within the blockchainprotocol itself, for example, according to an on-chain messagingprotocol, or outside of the blockchain protocol, either by way of ahuman or traditional (off-chain) communication protocol, a sidechain, oras application specific data or messages communicated in the payloadportion of a blockchain protocol data-, control-, or message-packet.Furthermore, or alternatively, nodes may be selected to participatebased on a random selection scheme, round robin scheme, weighted roundrobin scheme, etc.

FIG. 4 depicts a flow diagram illustrating a method 400 for implementinga distributed ledger technology method, in accordance with describedembodiments.

According to another embodiment as depicted at 400 in FIG. 4, at block405, processing logic for a blockchain platform host receives a requestto add a new block or transaction therein to a blockchain. The new blocktypically includes a number of transactions. In one embodiment, therequest is received from one of the nodes in a peer-to-peer network ofnodes that make up a consortium.

At logic block 410, the host receives from each of one or more of thenodes in a peer-to-peer network a weighted vote to add the new block ortransaction therein to the blockchain, in response to the request, or inresponse to a request for a vote issued by the blockchain platform host.These nodes learn of the request either through a blockchain protocolpacket broadcast by the node generating the request, or by communicationwith other nodes in the consortium or the blockchain platform hostproviding notice of the request in conjunction or combination with therequest for a vote transmitted by the blockchain platform host. At logicblock 415, the host validates, or receives validation of, the request toadd the new block or transaction therein to the blockchain when a sum ofthe received weighted votes exceeds a threshold. Finally, at logic block420 the host adds the validated new block or transaction therein to theblockchain.

According to one embodiment of the process depicted at 400 in FIG. 4, aconsortium of nodes participate in a private, or permissioned,blockchain. Each node is assigned a weight that its vote will be given,for example, based on domain (general) knowledge about the transactions,or types of transactions, the nodes can add to a new block in theblockchain. Before a node can add a transaction to a new block of theblockchain, or before the new block including the transaction can beadded to the blockchain, other nodes in the consortium vote on addingthe transaction to the new block for the blockchain and/or adding thenew block to the blockchain. When a majority of nodes agree thetransaction and/or new block should be added, the transaction and/or newblock is added. Nodes are weighted such that a “majority” may beobtained or denied based on the votes of one or more of the nodesparticipating in the private blockchain, that is, a majority may beobtained from less than all of the nodes participating in theblockchain.

According to this embodiment, the parties in the consortium agree uponthe weight, w, to assign each node in the consortium, for example, basedon a party's domain knowledge, and/or other criteria, including forexample, a party's participation in another blockchain or sidechain. Thetotal weight, W, of the nodes in the consortium is equal to sum of theindividual node weights, w₁+w₂+ . . . w_(n), where n is the number ofnodes in the consortium. The weight, w, of any one member, or the ratioof w/W may or may not exceed a certain threshold, in one embodiment.Each node's weight is attributed to the respective node's vote. If thesum of the weights for the nodes that voted exceed a certain threshold,the transaction/new block is validated and added to the blockchain. Inparticular, the transaction/new block is added if the total weight, W,attributed to the votes meets or exceeds a threshold (e.g., a plurality,majority, supermajority, in terms of percentage of w/W, or absolutevalue for w, whatever is agreed upon by the consortium) to reachconsensus for the blockchain. In this embodiment, the nodes in theblockchain do not need to come to unanimous agreement about adding thetransaction and/or new block to the blockchain, and indeed, after thethreshold is met, a node need not begin, or continue, to participate inthe voting process.

In one embodiment, at least a minimum number of nodes, k, vote on addinga transaction to the new block in the blockchain, or adding the newblock that includes the transaction to the blockchain, to mitigate therisk of fraud or double-spending, or to prevent one node with a largeweight, w, or a small group of nodes with a collectively large weight,from controlling the outcome of the vote. In one embodiment, the numberof nodes that participate in voting, k, or the ratio of k/n must meet aminimum threshold.

According to another embodiment of methods 200, 300, and 400, receivingthe request to add the new block to the blockchain comprises receivingfrom one of a plurality of nodes in the peer-to-peer network the requestto add the transaction to the new block in the blockchain.

According to another embodiment of methods 200, 300, and 400, validatingthe request to add the new block to the blockchain when consensus isreached according to the selected consensus protocol comprisesvalidating the request to add the new block to the blockchain whenconsensus is reached among a plurality of nodes in the peer-to-peernetwork according to the selected consensus protocol.

According to another embodiment of methods 200, 300, and 400, receivingthe request specifying one of a plurality of transaction types comprisesreceiving a blockchain protocol packet consisting of one of: anapplication specific data field in a payload portion of the blockchainprotocol data packet, and a field in a header portion of the blockchainprotocol data packet, that specifies the transaction type.

According to another embodiment of methods 200, 300, and 400, selectingone of a plurality of consensus protocols for validating the request toadd the new block to the blockchain, responsive to the specifiedtransaction type, comprises: searching for the specified transactiontype in a data store that associates each of the plurality oftransaction types with one of the plurality of consensus protocols; andobtaining the selected consensus protocol associated with the specifiedtransaction type, responsive to the searching.

According to another embodiment of methods 200, 300, and 400, selectingone of a plurality of consensus protocols for validating the request toadd the new block to the blockchain, responsive to the specifiedtransaction type, comprises a reinforcement learning-based softwareagent selecting the one of the plurality of consensus protocols forvalidating the request to add the new block to the blockchain, and thedistributed ledger technology platform host transmitting a blockchainprotocol packet consisting of one of: an application specific data fieldin a payload portion of the blockchain protocol data packet, and a fieldin a header portion of the blockchain protocol data packet, thatspecifies the selected one of the plurality of consensus protocols.

According to another embodiment of methods 200, 300, and 400, thereinforcement learning-based software agent selects the one of theplurality of consensus protocols for validating the request to add thenew block to the blockchain based on one or more of: the specifiedtransaction type, a consensus protocol selected for validating one ormore previous requests to add a new block to the blockchain that specifythe same transaction type.

According to another embodiment of methods 200, 300, and 400, validatingthe request to add the new block to the blockchain when consensus isreached according to the selected consensus protocol comprisesvalidating the request to add the new block to the blockchain whenconsensus is reached among participating nodes of a plurality of nodesin the peer-to-peer network according to the selected consensusprotocol.

According to another embodiment of methods 200, 300, and 400, validatingthe request to add the new block to the blockchain when consensus isreached among participating nodes of the plurality of nodes in thepeer-to-peer network according to the selected consensus protocolcomprises selecting the nodes in the peer-to-peer network to participatein the selected consensus protocol according to one of: a plurality ofrules, and a reinforcement learning-based software agent.

According to another embodiment of methods 200, 300, and 400, one of theselected consensus protocols comprises: receiving from each of one ormore of a plurality of nodes in a peer-to-peer network a weighted voteto add the new block to the blockchain, responsive to the request; andvalidating the request to add the new block to the blockchain when a sumof the received weighted votes exceeds a threshold.

According to a particular embodiment related to the methods 200, 300,and 400, there is a non-transitory computer readable storage mediahaving instructions stored thereon that, when executed by a distributedledger technology platform host, the host having at least a processorand a memory therein, cause the system to perform the followingoperations: receiving a request to add a new block to a blockchain, thenew block including a plurality of transactions, the request specifyingone of a plurality of transaction types; selecting one of a plurality ofconsensus protocols for validating the request to add the new block tothe blockchain, responsive to the specified transaction type; validatingthe request to add the new block to the blockchain when consensus isreached according to the selected consensus protocol; and adding the newblock to the blockchain, responsive to the validation of the request toadd the new block to the blockchain.

FIG. 5 depicts a flow diagram illustrating a method 500 for implementingdocument interface and collaboration using quipchain in a cloud basedcomputing environment, in accordance with described embodiments.

With reference to the flow diagram in FIG. 5, a document collaborationsystem that makes use of a blockchain-based distributed ledger toprovide for decentralized, replicated storage of shared documents orcontent, thereby improving the auditability and immutability of thedocuments is described. At logic block 505, a distributed ledgertechnology (DLT) platform host, for example, a node in ablockchain-based peer-to-peer network, receives a collaborative documentor portion thereof from a collaborative document processing application.In one embodiment, logic block 505 receives the collaborative documentor portion thereof from a first collaborator via a user interface for acollaborative document processing application. The user interface may beprovided on a client user device 106 by a desktop collaborative documentprocessing application executing on the user client device 106 that, inturn, communicates with the DLT platform host executing in hostorganization 110. In another embodiment, the user interface may beprovided on the client user device 106 by a web services-basedcollaborative document processing application executing on a hostedcomputing environment 111 that, in turn, communicates with the DLTplatform host executing in host organization 110, either within hostedcomputing environment 111 or a separate hosted computing environmentwithin host organization 110.

In one embodiment, the input regarding the collaborative documentreceived from the first collaborator includes but is not limited to:information regarding one or more of an identifier of the firstcollaborator (e.g., an email address or a user login identifier);identification of one or more additional collaborators with which thefirst collaborator is or intends to collaborate with; a message to beexchanged between the first collaborator and the additionalcollaborator(s) (e.g., a comment or question about, or collaborationnotes present alongside of, or version information for, a document); thedocument itself, or a portion thereof (e.g., a chapter, page, paragraph,clause, section, segment, etc.); the first collaborator's signature ofthe collaborative document; or a transaction regarding the document orthe portion thereof (e.g., the first collaborator requests creating,modifying, or deleting the document, or creating, modifying, or deletinga portion thereof in the document).

The host creates, at logic block 510, a blockchain asset that includesthe collaborative document or portion thereof. In addition, at logicblock 515, the host creates a blockchain transaction that includes theblockchain asset and a blockchain asset identifier. In one embodiment,the blockchain asset identifier is associated with a user—acollaborator—that actually signed the collaborative document. In oneembodiment, the host associates the blockchain asset identifier withinformation about the user obtained from the collaborative documentsystem or cloud computing environment with which the user interacts. Forexample, the user may have a login, or particular cryptographic key orsecurity information that identifies the user in the cloud computingenvironment and/or the collaborative document processing system.

At logic block 520, the host broadcasts the blockchain transaction intocirculation on a blockchain and listens for validation of the blockchaintransaction in response to broadcasting the blockchain transaction inthe blockchain. At logic block 525, the host receives validation. In oneembodiment, the receipt of validation of the blockchain transaction, inresponse to broadcasting the blockchain transaction into circulation onthe blockchain involves receiving validation of the blockchaintransaction from a second collaborator on the collaborative documentthat verified the first collaborator's signature of the collaborativedocument, as further described below. Thereafter, at logic block 530,the DLT host commits the validated blockchain transaction in a block tothe blockchain.

According to another embodiment, method 500 further includes: receivinginput regarding the collaborative document from the first collaboratorvia a user interface for a collaborative document processingapplication; and wherein the receiving of the collaborative documentfrom the collaborative document processing application includesreceiving, by the DLT host, the input regarding the collaborativedocument from the collaborative document processing application.

According to another embodiment of method 500, the receiving of inputregarding the collaborative document from the first collaboratorincludes receiving input regarding one or more of an identifier of thefirst collaborator, identification of one or more additionalcollaborators, a message to be exchanged between the first collaboratorand the additional collaborator(s), all or a portion of thecollaborative document, the first collaborator's signature of thecollaborative document, and a transaction regarding all or the portionof the collaborative document {e.g., insert, modify, delete}.

According to another embodiment of method 500, receiving validation ofthe blockchain transaction, responsive to broadcasting the blockchaintransaction into circulation on the blockchain includes receivingvalidation of the blockchain transaction from a second collaborator onthe collaborative document that verified the first collaborator'ssignature of the collaborative document.

According to another embodiment, the method 500 is further performed bya second distributed ledger technology (DLT) platform host, the secondhost having at least a processor and a memory therein, the methodincluding: receiving the blockchain transaction broadcasted intocirculation on the blockchain; providing the collaborative document orportion thereof from the received broadcasted blockchain transaction toa collaborative document processing application; receiving validationregarding the collaborative document from a second collaborator on thecollaborative document that verified the first collaborator's signatureof the collaborative document; and broadcasting the validated blockchaintransaction into circulation on a blockchain.

According to another embodiment of method 500, receiving validation ofthe blockchain transaction, responsive to broadcasting the blockchaintransaction in the blockchain, includes receiving the validation of theblockchain transaction, responsive to receiving the validated blockchaintransaction broadcasted into circulation on the blockchain.

According to another embodiment of method 500, receiving validationregarding the collaborative document from a second collaborator on thecollaborative document that verified the first collaborator's signatureof the collaborative document includes receiving validation regardingthe collaborative document from the second collaborator via a userinterface for the collaborative document processing application.

According to another embodiment, the method 500 is further performed bythe second DLT platform host, the method further including: receiving asecond collaborative document or portion thereof from the collaborativedocument processing application; creating a second blockchain assetincluding the second collaborative document or portion thereof; creatinga second blockchain transaction including the second blockchain assetand a second blockchain asset identifier associated with the secondcollaborator that countersigned the second collaborative document;broadcasting the second blockchain transaction into circulation on theblockchain; receiving validation of the second blockchain transaction,responsive to broadcasting the second blockchain transaction in theblockchain; and committing the validated second blockchain transactionin a second block to the blockchain.

In accordance with a particular embodiment, there is a non-transitorycomputer readable storage media having instructions stored thereon that,when executed by a distributed ledger technology platform host, the hosthaving at least a processor and a memory therein, cause the system toperform the following operations: receiving a collaborative document orportion thereof from a collaborative document processing application;creating a blockchain asset including the collaborative document orportion thereof; creating a blockchain transaction including theblockchain asset and a blockchain asset identifier associated with afirst collaborator that signed the collaborative document; broadcastingthe blockchain transaction into circulation on a blockchain; receivingvalidation of the blockchain transaction, responsive to broadcasting theblockchain transaction in the blockchain; and committing the validatedblockchain transaction in a block to the blockchain.

FIG. 6A depicts a flow diagram illustrating a method 600 forimplementing a distributed ledger technology method, in accordance withdescribed embodiments.

In accordance with further embodiments as described herein, and withreference to the flow diagram in FIG. 6A, at logic block 605, a seconddistributed ledger technology (DLT) platform host, for example, a secondnode in a blockchain-based peer-to-peer network, receives theabove-mentioned blockchain transaction broadcast into circulation on theblockchain by logic block 520. The DLT platform host processes thebroadcasted transaction, including extracting from the payload portionthereof the collaborative document or portion thereof and provides, atlogic block 610, a copy of the document or portion thereof to acollaborative document processing application.

At logic block 615, the collaborative document processing applicationreceives validation regarding the collaborative document from a secondcollaborator via a user interface for the collaborative documentprocessing application. The validation on the collaborative documentverifies the first collaborator's signature of the collaborativedocument. The collaborative document processing application communicatessuch to the DLT platform, which, in turn, at logic block 620, validatesthe corresponding blockchain transaction and broadcasts the validatedblockchain transaction into circulation on a blockchain.

FIG. 6B depicts a flow diagram illustrating a method 660 forimplementing a distributed ledger technology method, in accordance withdescribed embodiments.

In accordance with further embodiments as described herein, and withreference to the flow diagram in FIG. 6B, at logic block 625 the secondDLT platform host, in turn, can receive a second collaborative documentor portion thereof from the collaborative document processingapplication. For example, if the second collaborator revises the firstdocument sent by the first collaborator (e.g., inserts, modifies, orremoves content), or creates a new document relating to but independentof the first document, the collaborative document processing applicationprovides a copy of such to the second DLT platform host. For example,the second collaborator may simply countersign the first document,creating thereby a second, countersigned document. At logic block 620,the second host creates a second blockchain asset comprising the secondcollaborative document or portion thereof, and at logic block 635,creates a second blockchain transaction that includes the secondblockchain asset and a second blockchain asset identifier associatedwith the second collaborator, e.g., that countersigned the secondcollaborative document.

At logic block 640, the second DLT host broadcasts the second blockchaintransaction into circulation on the blockchain and listens forvalidation of the second blockchain transaction in response tobroadcasting the second blockchain transaction in the blockchain. Atlogic block 645, the second host receives validation. In one embodiment,the receipt of validation of the second blockchain transaction, inresponse to broadcasting the second blockchain transaction intocirculation on the blockchain involves receiving validation of thesecond blockchain transaction from the first collaborator on thecollaborative document that verified the second collaborator's signatureof the collaborative document, in the same manner as described abovewith regard to logic blocks 605-620. Thereafter, at logic block 650, thesecond DLT host commits the validated second blockchain transaction in ablock to the blockchain.

FIG. 7A depicts another exemplary architecture 700, with additionaldetail of a blockchain which implements community sidechains withconsent management, in accordance with described embodiments.

As depicted here, there is again a host organization 110 having a hostedcomputing environment 111 operating therein with a web-server 175,request interface 176, authenticator 140, query interface 180, anddatabase system 130. As before, there is also a blockchain servicesinterface 190 via which the host organization 110 provides a variety ofblockchain related services to customers, subscribers, and otherorganizations and tenants which utilize the cloud computing servicesprovided by the host organization 110.

More particularly, there is now depicted within the blockchain servicesinterface 190 a blockchain consent manager 705 which implementscommunity sidechain functionality with consent management to controlaccess rights, readability, exchange permissions and disclosurecapabilities of the payload data stored within the blockchain.

Conventionally, blockchain blocks are fully open and readable to anyparticipating node for the blockchain protocol implementation. Suchopenness is by design as it permits any node to authenticate andvalidate that transactions are valid independently, without requiringpermission from any authority. However, such openness is not alwaysdesirable. Therefore, the blockchain consent manager 705 and theblockchain services interface 190 expose additional functionality forcertain blockchain protocol implementations supported by the hostorganization which permit certain data to be subjected to additionalaccess restrictions, while nevertheless utilizing and benefiting fromthe distributed ledger technologies embodied within the blockchainfunctionality.

According to a particular embodiment, the blockchain consent manager 705provides a community sidechain with consent management on a privateblockchain. As depicted here, the blockchain consent manager 705provides a private blockchain 740 (e.g., a community sidechain) which iscomprised of an initial genesis block 741 beginning the sidechain as aprivate blockchain 740 followed by a sequence of standard blocks 743 asthe private blockchain continues to grow. The private blockchain 740 isaccessible to each of the participating nodes 750A and 750B and 750C. Inpractice, there are likely to be many more participating nodes for theprivate blockchain 740.

Community sidechains are useful where it is desirable to share databetween two nodes of a blockchain, for instance, such as the ability toshare medical information for a patient between a hospital and aninsurance provider.

With conventional mechanisms, every participating node 750A-C has fullaccess to all data once that data is written into the blockchain. Whileuseful in many situations, it is readily apparent that medicalinformation should not be freely accessible to view due to privacyconcerns as well as HIPAA (Health Insurance Portability andAccountability Act of 1996) requirements. Notwithstanding theshortcomings, or design feature, of prior blockchain protocolimplementations, which permit full visibility, the blockchain consentmanager j705 of the host organization 110 provides specific customers,organizations, users (e.g., hospitals, doctor offices, insuranceproviders, etc., within the context of the patient medical recordsexample) to benefit from the use of blockchain functionality such asimmutability and non-centralized record keeping, while also respectpatient privacy and comply with Federal HIPAA requirements. Financialorganization have similar legal requirements to protect privateinformation, yet may also benefit from the blockchain functionality asset forth herein to provide community sidechains with consent managementcapabilities via the blockchain consent manager 705.

According to one embodiment, the blockchain consent manager 705implements a consent management layer 710 through which participatingnodes 750A-C must traverse if they wish to view, read, or access certaininformation stored within the private blockchain 740. According to suchan embodiment, some of the data within the private blockchain 740 isviewable to all participating nodes 750A-C whereas other data isrestricted.

Unlike the distinction between a private blockchain and a publicblockchain, in which anyone can access the public blockchain and viewany information within it, and anyone having access to the privateblockchain can access any information within it, the private blockchain740 with consent management is different because even if a participatingnode has authority to access the private blockchain 740, such accessdoes not necessarily confer the “consent” by which to access protectedor restricted information stored within the private blockchain 740.

As depicted here, participating node 750A has provided consent 751 whichis written into the private blockchain 740. Consequently, a newsidechain community 761 is formed by the blockchain consent manager 705.Specifically, the blockchain consent manager 705 creates a new communitysidechain 760 formed from sidechain blocks 742. The community sidechain760 is formed from the point of the fork block 742 which is viewed bythe private blockchain 740 as a standard block, but includes a referencelinking the newly formed community sidechain 760 with the privateblockchain 740. The main private blockchain 740 then continues on afterthe creation of the community sidechain 760 via additional standardblocks 743 which follow the fork block 742.

Upon the consent 751 being received from participating node 750A andbeing written into the private blockchain 740, the blockchain consentmanager 705 seeds the new community sidechain 752 with the consent, thusforming the new community sidechain 760. According to certainembodiments, no payload data whatsoever is written into the sidechainblocks 742 of the community sidechain. For example, the protected data753 is not written into the community sidechain 760, but rather, remainswithin the private blockchain 740 in protected form, but is accessibleto the participating nodes of the sidechain community 761 via areference between the sidechain blocks 742 accessible only to theparticipating nodes 750A and 750B of the sidechain community whichpermits retrieval of the protected data 753 through the consentmanagement layer. In other embodiments, protected data 753 may bewritten into the payload of the sidechain blocks 742, and through virtueof the participating nodes 750A and 750B residing within the sidechaincommunity 761, those participating nodes 750A and 750B will have accessto the protected data 753 without having to access the main chain (e.g.,the primary blockchain 740). As depicted here, the community sidechain760 is linked to the private blockchain 740, and may therefore beconsidered a forked blockchain, whereas in other implementations, thecommunity sidechain may be formed and permitted to operate independentlyfrom the private blockchain, so long as the blockchain consent manager705 remains in control to manage which participating nodes are permittedto form any newly created sidechain community 761, and therefore, whichparticipating nodes have access to the protected data 753 and whichparticipating nodes do not have access to the protected data 753.

As is depicted here, participating nodes 750A and 750B have access tothe sidechain as they form the entirety of the sidechain community 761,and thus, data is sharable between the nodes of the sidechain community,whereas the participating node 750C is not a member node of thesidechain community 761, and therefore cannot access the protected dataand cannot share data with the participating nodes 750A and 750B.

FIG. 7B depicts another exemplary architecture 701, with additionaldetail of a community sidechain with consent management, in accordancewith described embodiments.

Depicted here are further details regarding the introduction of newparticipating nodes into the private blockchains. As shown here, therenow exists two distinct private blockchains which are managed by theblockchain services interface 190, specifically, the healthcareblockchain 744 and the construction blockchain 743. According todescribed embodiments, there can be many different private blockchains,and they may be organized in a variety of ways. For instance, it isconceivable that different parties in the healthcare industry may wishto share data amongst one another, and therefore, they may participatewithin the same private healthcare blockchain 744, and where datasharing is needed, consent may be granted, a sidechain formed with theparticipating nodes needing access to the data to be shared, thusforming a sidechain community, and then the data shared amongst thoseparticipants of the newly created sidechain community, just as wasdescribed above.

However, there may be other participants which have no need for accessto medical data, and therefore, those participating nodes are formedinto a distinct private blockchain. For instance, depicted here is theconstruction blockchain 743 having participants such as hardware stores,construction materials manufacturers, building contractors, etc. Whilesuch actors likely have no need to access medical information, theylikely would benefit from the ability to securely share data related totheir construction industry, such as purchase orders, building plans,construction contracts, etc. These actors may wish to protect certaintypes of information, yet may nevertheless benefit from the use ofblockchain functionality.

According to a particular embodiment, a new user registration (e.g., forinstance the creation of a user profile with a website, etc.) within themain construction blockchain 743 resulting in the creation of a new userspecific community sidechain 756. Initially, the new user registrationis the only participating node for the user specific community sidechain756 as only that particular user by default will have access to privateand protected data. However, the new user registration node 755 mayconsent 751 to another node, with the consent being written into theconstruction blockchain 743 (e.g., being written into the fork block 742by way of example), thus resulting in the community sidechain 756 havinghow having both the new user registration 755 and also anotherparticipating node to whom consent was granted. As shown here,participating node 750B previously was part of the constructionblockchain 743 with no access to the sidechain, however, upon the grantof consent for the new user registration node, the participating node750B is then joined into the user specific community sidechain 756,through which access to private or protected data associated with thenew user registration node 755 may be shared. All nodes having consentto enter the user specific community sidechain 756 will be given accessto the private and protected information of the new user registrationnode 755. If the same user requires different access to be given todifferent participating nodes, then the user would require a separatenew user registration node to be created. For example, if a user createsa profile with a website such as Home Depot or Lowe's within theconstruction blockchain 743 and elects to share information, forinstance with a carpet installer, then consent may be granted to thecarpet installer to join the user specific community sidechain 756 andaccess the relevant information. If the user wishes then to share thesame information with, for example, a window installer, then the windowinstaller may also be given consent 751 to join the user specificcommunity sidechain 756 as a new participating node, however, if theuser wishes to share different information with each provider, then twoprofiles would be required. Pragmatically, however, the same informationfor the user would be pertinent to each installer, and therefore, it isunlikely that the user encounters such problem.

It is therefore in accordance with a particular embodiment that usersmay create user specific community sidechains within the primaryblockchain (e.g., such as the construction blockchain 743 or thehealthcare blockchain 744, etc.) by creating a user profile with aparticipating website and such users may then grant consent to othernodes (e.g., via the same website) to permit sharing of their private orprotected information with specified target nodes participating withinthe primary blockchain but without access to the user specific sidechainbefore being granted consent.

Although not specific to the concepts which are discussed in detailherein, a website, such as Home Depot, may operate as a node within theconstruction blockchain 743 and also as a customer of the hostorganization. Through the website of the customer Home Depot, new usersmay create user profiles and the blockchain services interface 190 ofthe host organization will then generate a new node within theconstruction blockchain 743 or other relevant primary blockchaincorresponding to the new user registration 755. The blockchain servicesinterface 190 will additionally generate the user specific communitysidechain 756 via which the user may grant consent to share informationwith other participating nodes for the particular blockchain, such asthe construction blockchain in this example. For instance, according toone embodiment, when users login or create a profile with the website,such as with Home Depot, they are authenticating with the hostorganization 110 upon which the website operates and resides. Becausethe user is then authenticated with the host organization 110, the samehost organization 110 can then create the new node for the new userregistration on any blockchain accessible to the host organization 110through the blockchain services interface 190.

To be clear, information is not shared between two different privateblockchains. Therefore, while technically feasible, it is notcontemplated that information would be shared between the healthcareblockchain 744 and the construction blockchain 743. Rather, eachoperates as a separate private blockchain, each with its ownparticipating nodes, users, and sidechains. The same human user could,however, create profiles with different websites resulting in that humanuser having a node within the healthcare private blockchain and also anode within the construction private blockchain. The fact that bothprivate blockchains are managed by the same host organization isirrelevant and would likely be unknowable to the particular user inquestion.

It should also be noted that a sidechain of the private blockchain isnot a node, but rather, a permissible branch, or fork, from the mainprivate blockchain. The sidechains depicted here remain immutablyattached to, and associated with the primary blockchain and do notoperate independently. However, if information is to be shared withanother independently operated blockchain, such as another healthcareprivate blockchain separate from the healthcare blockchain 744 managedby the host organization 110, then the user could grant consent toexchange protected data with other independently operated blockchain inthe manner described previously (e.g., at FIG. 1D), assuming a definedexchange agreement exists between the two primary blockchains, in whichcase the healthcare blockchain 744 managed by the host organizationwould be considered the parent blockchain (e.g., element 188 at FIG. 1D)and the separate independently operated blockchain would be treated asthe independently operated sidechain (e.g., element 189 at FIG. 1D).

According to a particular embodiment, when user consent is captured fora particular node within the user specific sidechain, the consent iscaptured at the sidechain and then written into the primary blockchainwhere it is permanently kept. In such an embodiment, the fact thatconsent has been granted is not protected information, however, therestricted data is protected and the consent is only applicable to aspecified participating node of the primary blockchain until such timethat consent is rescinded. According to certain embodiments, the consentgranted may be time limited, and will therefore expire after a specifiedperiod of time. In such case, access to the protected information ischecked against the time expiration via the blockchain consent manager705 as part of the blockchain protocol provided by the blockchainservices interface 190.

FIG. 8A depicts another exemplary architecture 800, with additionaldetail of a blockchain which implements super community sidechains withconsent management, in accordance with described embodiments.

As depicted here, there is again a host organization 110 having a hostedcomputing environment 111 operating therein with a web-server 175,request interface 176, authenticator 140, query interface 180, anddatabase system 130. As before, there is also a blockchain servicesinterface 190 via which the host organization 110 provides a variety ofblockchain related services to customers, subscribers, and otherorganizations and tenants which utilize the cloud computing servicesprovided by the host organization 110.

An important improvement to prior blockchain technology as describedherein is the ability to share information between different tenants ofthe host organization 110. Notably, however, sharing of information hasits own demerits as it requires proper consent from the user when thatuser's information is to be shared.

Consider an example where two or more tenants of the same hostorganization 110 participate within the same private blockchain, such asa first tenant Home Depot and a second tenant AAA Carpet Installersparticipating within a private construction blockchain. Each of thetenants operate as a node within the private construction blockchainprovided by the blockchain services interface 190 of the hostorganization. When a user creates an account with the Home Depot websitewhich is a tenant of the host organization 110, that user's data andcredentials are stored by the host organization 110 and the hostorganization creates a node within the private construction blockchainfor the user, as described above. However, if the same human usercreates a login and profile with another tenant of the hostorganization, then the user will again have a node created within theprivate construction blockchain for the user, but each will havedifferent unique identifiers, each will be different nodes, and thelogin credentials and profiles for the same human user will be distinct.

This is a common experience as individuals creating a user profile at,for example, Kaiser healthcare may also create a user profile at, forexample, Prudential healthcare. Such individuals would not expect thesame login credentials to work at both distinct organizations, andindeed, the individual's user profiles are distinct and maintained quiteseparately.

However, when the two separate organizations are both tenants of thesame host organization, the super community tenant bridge 805 provides amechanism by which the same human user is enabled to share informationbetween the two distinct user profiles.

Consider for example an individual who walks into a Bank, say WellsFargo, and opens an account. The user will need to provide significantinformation to the bank, beyond just the individual's name. Forinstance, the user may be required to supply address, employer, income,marital status, financial assets, social security number, etc. Then thesame individual goes to another bank, such as Chase, to open a creditcard, predictably, the second bank is going to request much of the sameinformation from the same individual as did the first bank. This isfrustrating for the individual and time consuming. Similarly, if theindividual seeks treatment from a doctor, upon visiting, the doctor'soffice will request a litany of personal medical information. If thatsame doctor then sends the individual to the hospital for treatment, thehospital will then request the identical information from the sameindividual, despite such information having already been provided to thedoctor.

The super community tenant bridge 805 overcomes this problem for anindividual where both organizations requesting information are tenantswithin the same host organization 110. Notwithstanding the fact that theindividual will have a first user profile 810A with one tenantorganization and a different user profile 852 with the second tenantorganization, the host organization 110 nevertheless possessesinformation about both tenants and can facilitate a data sharing processusing blockchain protocols provided by the host organization'sblockchain services interface 190, subject to proper consent by theindividual with whom both user profiles 851 and 852 are actuallyassociated.

As depicted here, an individual already has a user profile with customerorganization 810A, represented by user profile 851. Within the userprofile is information the individual has provided or entered, such aspersonal medical data provided to a doctor's office. Assuming both thedoctor's office (as customer organization 810A) and a second customerorganization 810B, such as a hospital, are both tenants of the hostorganization 110 and both utilizing the blockchain services provided bythe host organization 110 and are therefore each participating nodes onan applicable blockchain (e.g., such as a healthcare private blockchainmanaged by the host organization), then the individual can login andauthenticate as a known user with either of the two customerorganizations 810A and 810B and grant user consent 891 to shareinformation between the two customer organizations, resulting in theuser's protected information being shared as depicted by element 892,with the user's protected information being provided to and replicatedwithin customer organization 810B by the super community tenant bridge805.

Know your customer or “KYC” is the process of a business identifying andverifying the identity of its clients. The term is also used to refer tothe bank and anti-money laundering regulations which governs theseactivities. The objectives of KYC guidelines is to prevent banks frombeing used, intentionally or unintentionally, by criminal elements formoney laundering activities. Related procedures also enable banks tobetter understand their customers and their financial dealings. Thishelps them manage their risks prudently.

Some of the KYC policies are effectively mandated by Federal law whichrequire extensive verification of any individual with whom the bank doesbusiness.

Similar requirements exist with respect to healthcare organizationswhich must ensure that the person they are speaking with, treating, orproviding insurance covered services to, is indeed, the correctindividual.

Banks and healthcare organizations incur very high costs in gatheringsuch data and performing the necessary validation upon any individualwith whom they interact, and consequently, it is not just aninconvenience for the individual who must provide the same informationover and over to multiple different organizations, but the organizationsrequesting the information also are inconvenienced.

The super community tenant bridge 805 addresses this need by utilizing ablockchain protocol defined by the host organization 110 to store therelevant information and then using the blockchain services interface190 and the super community tenant bridge 805 to enable sharing ofrepetitive but private and protected information between consentingparties, such as two banks or two healthcare organizations, etc. Thisbenefits the individual who is unburdened from having to provideidentical information over and over to multiple providers, and thisbenefits the providers or customer organizations who receive, subject touser consent 891, accurate information more quickly, but also benefitfrom the fact that the information is stored within a blockchain and istherefore significantly less risky given the computationally burdensomeand generally infeasible means by which to maliciously or fraudulentlymanipulate the blockchain.

As the information for a particular individual accumulates within theblockchain and becomes more seasoned (e.g., older in the blockchain),the information will be deemed increasingly reliable and authentic, andis therefore more trustable to the banks, healthcare organizations, orother entity relying upon such information.

For example, if an individual has provided their drivers license andinsurance card to a first organization, such as the doctor's office, andsuch information is then stored within the blockchain, then a secondorganization, such as the hospital, has little reason to question theinformation in the blockchain given that the second organization canboth validate the blockchain block itself and also given the fact thatbecause the information is in the blockchain, another provider, thedoctor's office, is already attesting to the veracity of theinformation.

FIG. 8B depicts another exemplary architecture 801, with additionaldetail of GUI 803 at a user device 899 interacting with super communityfunctionality, in accordance with described embodiments.

As can be seen here, an individual may utilize a user computing device899 such as the one shown to search the blockchain for all profilesassociated with their universal ID which is unique to that individualwithin the host organization 110.

As shown here, the super community tenant bridge 805 transmits a GUI tothe user device which is then displayed, thus permitting the user toenter their universal ID to search for associated profiles. In otherembodiments, the user may search for their Universal ID if they areunsure, or navigate a search function to locate their universal ID,which is then used to search for all associated user profiles for theindividual.

Ordinarily, a user would be required to log in to each system separatelydue to the two separate and distinct user accounts or user profiles,even if both customer organizations were tenants of the same hostorganization 110 as the language, authentication, and user interfaceswere unique to each respective customer organization. However, the supercommunity tenant bridge 805 permits users to identify all accountsacross multiple tenant organizations within the host organization 110for which the individual has data or user profiles stored within theblockchain and then from a simple GUI interface, identify which elementsor what kinds of data the individual wishes to share between the twodistinct customer organizations.

FIG. 8C depicts another exemplary architecture 802, with additionaldetail of GUI 804 at a user device 899 interacting with super communityfunctionality, in accordance with described embodiments.

As depicted here, the user is prompted at GUI 804 with a request toshare documents and information and the user may choose which documentsand information to be shared as shown at operation 819. The informationhere is originating from the first customer organization with whom theuser already has created a profile and entered or provided theinformation, and will be shared with the second customer organization.In certain embodiments, the information is replicated to the secondcustomer organization, whereas in others, the second organization isgranted consent to share the information and the second customerorganization is then placed into a community sidechain with the user'snode via which the information may traverse the consent management layer(e.g., element 710 of FIG. 7C) to gain access to the requiredinformation within the primary blockchain without having to replicatethe data. Generally, non-replication is preferable as the sameinformation has already been validated and exists within a validatedblock having consensus of all participating nodes on the blockchain,however, certain implementations may necessitate data replication ratherthan consent for data access to originally stored information within theblockchain.

Once the user unlocks the chosen data elements to be shared and clickssubmit, consent is then granted to the second customer organization inthe manner described above.

According to described embodiments, the individual authenticates witheither the first or the second customer organization, in which onecustomer organization has access to the individual's protected data andin which the other customer organization does not, and then the userapproves the sharing of data by granting consent either within thecustomer organization having access to the data already or grantsconsent to receive the shared data within the customer organizationwhich does not have access to the data. Stated differently, it doesn'tmatter which user profile the individual authenticates with so long asboth are associated with the same universal ID for that particularindividual.

Once consent is granted by the user, because both customer organizationsare participating nodes for the blockchain, they may then read the datafrom the blockchain and traverse the consent management layer (e.g.,element 710 at FIG. 7B) implemented by the blockchain consent manager(e.g., element 705 at FIG. 7B).

According to one embodiment, the universal ID for a healthcareblockchain is an individual's social security number (SSN) whereas inother embodiments, it is a value generated by the host organization. Forother embodiments implementing FinTech for financial institutions, theuniversal ID may be a business' Tax ID Number or (TIN). Otherblockchains for different industries may utilize different numbers ormay utilize a universal ID generated by the host organization for eachunique individual having one or more profiles with tenants of the hostorganization. The universal ID is sometimes referred to as the“blockchain identifier.” While every user profile with every tenant maybe distinct and even have a distinct User ID for that user profile, theuniversal ID is common amongst all user profile for a particularindividual.

According to certain embodiments, when an individual authenticates withany tenant's website, the individuals universal ID is automaticallypopulated or retrieved such that the individual need only grant consentor decline to grant consent, without having to enter their universal IDor search for their universal ID. For instance, where there is a perfectmatch to a user's profile data based on the blockchain, then the matcheddata may be utilized to automatically populate the universal ID withoutthe user having to provide it or search for it. For instance, a perfectmatch may require a matching SSN/TIN, first name, last name, and date ofbirth (DOB) based on the blockchain.

In other embodiments, two factor authentication is required before anyconsent may be granted based on an individual's universal ID so as toenhance security and the risk of inadvertent sharing of protected datastored within the blockchain.

According to other embodiments, two user profiles which are notassociated with a common universal ID may be linked to a commonuniversal ID utilizing two factor authentication to verify the at thesame individual is in control of both accounts as well as another pieceof known information, such as a cell phone number or an email account.With the two factor authentication, the individual may then attest thatthey are indeed the same individual.

According to certain embodiments, a user's universal ID may be searchedfor and located using personal verification information, such as theindividuals SSN or TIN, date of birth, other information knowable to theindividual but difficult for others to find.

By providing identity management on behalf of an individuals many userprofiles amongst the various tenants of the host organization it ispossible to add a much stricter consent management layer which must betraversed to access protected information from the blockchain whereasconventional blockchain implementations permit all data within theblockchain to be freely accessed by any participating node. In certainembodiments, it is not the individual which grants consent, but rather,the nodes themselves (e.g., such as a company representative to whom thenode belongs). In such a way, nodes may also consent to share data withother nodes, which may not necessarily correspond to an individual humanuser.

Once an individual lugs in to one of the two customer organization'swebsites, is prompted for consent to share information, andaffirmatively grants consent, then the blockchain consent manager 705 inconjunction with the super community tenant bridge 805 will establishset up the individual's blockchain asset within the blockchain and jointhe customer organization's node now having consent into a communitysidechain with the user's node and the customer organization's nodehaving prior access to the user's protected data, such that all nodes inthe community sidechain are enabled to access the protected data in theblockchain.

In such a way, rather than the same individual having to log in to twoseparate communities (e.g., a community sidechain corresponding to eachdistinct user profile), they are all joined into one community sidechainspanning the individual's multiple user profiles across multipledistinct tenants of the host organization 110.

According to one embodiment, the user's protected data is owned by anode corresponding to the first customer organization, however, theright to grant consent for the first customer organization to share thedata is retained by the individual. Therefore, the individual's consentto share the information permits two nodes participating on theblockchain to share information by being placed into a common communitysidechain, however, because, in this example, the user's node does notown the data, it is not necessary for the user's node to be placed intothe same community sidechain nor is it necessary for the two customerorganizations which are to participate in the data sharing to join thecommunity sidechain within which the user's node resides.

As depicted at GUI 804, the various types of data may be broken out asseparate categories or different types, and therefore, a user couldgrant consent to share a blood test document owned by a hospital nodewith a node representing the individual's doctor's office, yet denyconsent to share the financial assets, thus prohibiting the hospitalfrom sharing the financial information with the doctor's office, even inthe event such info was requested and the user was prompted for consentto share the information.

According to another embodiment, the user may click on each category andselect specifically which documents, objects, or fields to share or notshare, thus providing the user with greater granularity control over theinformation for which consent to share is granted.

According to described embodiments, granted consent is written into thepayload of a blockchain protocol block where all nodes in the blockchainmay view and validate the consent as a separate blockchain asset, withthe node being given consent having a link via which to pierce theconsent management layer to access the user's protected informationwhich is already written into the blockchain but which is inaccessibleto all nodes lacking express consent from the user. According to oneembodiment, the link is the asset ID within the blockchain.

According to such an embodiment, the node being given consent onlyrequires the asset ID to access the protected information stored withinthe blockchain.

According to a particular embodiment, a super-community is establishedwhich is an amalgamation of small communities, each smaller communitybeing made up of each of the customer organizations that areparticipating in the blockchain. Whenever data is requested from theblockchain a notification is transmitted to the entire super-communityand the consent model is then enforced by the blockchain consent manager705. In such an embodiment, consent will identify or include at least(i) the blockchain asset that is requested from the blockchain, (ii) thecustomer organization (e.g. tenant) that is requesting access, (iii) theconsumer that owns that data or from whom permission must be obtained,and (iv) the records for which access is being requested. Within thecommunity GUI, a UI component displays to the community user all therequested approvals for that particular user within the super community.User access is pre-provisioned by the identity management of the hostorganization, for instance, via authenticator 140. Community users inthe super community can then decide whether to grant consent as well asdrill down for more granular control as to which assets are to beshared, with what other customer organizations (e.g., tenants) thoseassets are to be shared, thus controlling who has access to what data.

FIG. 9 depicts a flow diagram illustrating a method 900 for implementingSuper community and community sidechains with consent management fordistributed ledger technologies in a cloud based computing environmentsuch as a database system implementation supported by a processor and amemory to execute such functionality to provide cloud based on-demandfunctionality to users, customers, and subscribers.

Method 900 may be performed by processing logic that may includehardware (e.g., circuitry, dedicated logic, programmable logic,microcode, etc.), software (e.g., instructions run on a processingdevice) to perform various operations such as executing, transmitting,receiving, analyzing, triggering, pushing, recommending, defining,retrieving, parsing, persisting, exposing, loading, operating,generating, storing, maintaining, creating, returning, presenting,interfacing, communicating, querying, processing, providing,determining, displaying, updating, sending, etc., in pursuance of thesystems and methods as described herein. For example, the hostedcomputing environment 111, the blockchain services interface 190, andits database system 130 as depicted at FIG. 1, et seq., and othersystems and components as described herein may implement the describedmethodologies. Some of the blocks and/or operations listed below areoptional in accordance with certain embodiments. The numbering of theblocks presented is for the sake of clarity and is not intended toprescribe an order of operations in which the various blocks must occur.

With reference to the method 900 depicted at FIG. 9, at block 905,processing logic operates a blockchain interface to a blockchain onbehalf of a plurality of tenants of the host organization, in which eachof the plurality of tenants are participating nodes with the blockchain.

At block 910, processing logic receives a login request from a userdevice, the login request requesting access to a user profile associatedwith a first one of the plurality of tenants.

At block 915, processing logic authenticates the user device andretrieving a user profile from the blockchain based on theauthentication of the user device, in which the user profile is storedas a blockchain asset within the blockchain with a first portion of theuser profile including non-protected data accessible to allparticipating nodes on the blockchain and with a second portion of theuser profile including protected data accessible only to participatingnodes having user consent.

At block 920, processing logic prompts the user device to grant userconsent to share the protected data with a second one of the pluralityof tenants.

At block 920, processing logic shares the protected data with the secondone of the plurality of tenants by permitting access to the protecteddata within the blockchain asset by the second tenant's participatingnode.

According to another embodiment of method 900, a blockchain consentmanager of the host organization requires an asset ID to access theprotected data from the blockchain.

According to another embodiment, method 900 further includes: receivinga request from the second tenant to create a second user profile;creating a blockchain asset including the non-protected information forthe second user profile; generating, via a blockchain servicesinterface, a blockchain transaction including the blockchain asset;broadcasting the blockchain transaction into circulation on theblockchain; and committing the validated blockchain transaction in ablock to the blockchain.

According to another embodiment of method 900, prompting the user deviceto grant user consent to share the protected data with a second one ofthe plurality of tenants includes: prompting the user device to sharethe protected data with the second tenant to populate the second userprofile, in which both the first user profile and the second userprofile are associated with a common universal ID; and in which sharingthe protected data with the second one of the plurality of tenantsincludes populating the second user profile with the protected dataretrieved from the blockchain asset by the second tenant's participatingnode.

According to another embodiment of method 900, sharing the protecteddata with the second one of the plurality of tenants by permittingaccess to the protected data within the blockchain asset includessending an asset ID for the blockchain asset to the second tenant; andin which the method further includes the second tenant presenting theasset ID to a blockchain consent manager to access the protected datawithin the blockchain asset.

According to another embodiment of method 900, each of the first andsecond tenants are healthcare customer organizations operating asparticipating nodes with a healthcare blockchain managed by the hostorganization; in which the non-protected data includes at least a nameof a user associated with the first user profile; in which the protecteddata includes at least HIPAA (Health Insurance Portability andAccountability Act) protected medical data stored within the healthcareblockchain via the blockchain asset having the first user profileembodied therein on behalf of the user; and in which sharing theprotected data with the second one of the plurality of tenants includesthe user granting consent to share the HIPAA protected medical data withthe second tenant via a second user profile associated with the secondtenant.

According to another embodiment of method 900, each of the first andsecond tenants are financial customer organizations operating asparticipating nodes with a financial blockchain managed by the hostorganization; in which the non-protected data includes at least a nameof a user associated with the first user profile; in which the protecteddata includes at least private financial data stored within thefinancial blockchain via the blockchain asset having the first userprofile embodied therein on behalf of the user; and in which sharing theprotected data with the second one of the plurality of tenants includesthe user granting consent to share the private financial data with thesecond tenant via a second user profile associated with the secondtenant.

According to another embodiment, method 900 further includes: receivingthe user consent to share the protected data by one of: (i) receivingthe user consent from an authenticated user of the second tenant havingbeen verified as a same individual associated with the first tenant; or(ii) receiving the user consent from the user device authenticated withthe first tenant having been verified as a same individual associatedwith the second tenant.

According to another embodiment of method 900, sharing the protecteddata with the second one of the plurality of tenants includes the hostorganization validating, via a blockchain consent manager, that both thefirst tenant and the second tenant have a user profile associated withone individual; and in which the validating is based on receivingattestation from the one individual that both the first and secondtenant's user profiles are associated with a common universal ID whichis unique to the one individual within the host organization.

According to another embodiment of method 900, the blockchain asset isidentified via a blockchain asset identifier or a Universal ID uniquewithin the blockchain; and in which one individual associated with theprotected data is uniquely identifiable to both the first tenant and thesecond tenant of the host organization based on the blockchain assetidentifier or the Universal ID.

According to another embodiment, method 900 further includes: creating aparticipating node with the blockchain for a user associated with theuser profile; generating a user specific community sidechain for theuser associated with the user profile; adding both the first tenant'snode and the second tenant's node to the user specific communitysidechain; and in which sharing the protected data includes grantingaccess to the protected data to all nodes within the user specificcommunity sidechain.

According to another embodiment of method 900, any attempt by aparticipating node with the blockchain to access the protected data ofthe user profile triggers the prompting of the user device to grant userconsent to share the protected data with the participating nodeattempting access; in which a GUI is transmitted to the user device witha request to unlock specific categories of protected information or tounlock specific documents, or both; in which the user selects whichcategories and/or documents to unlock via the GUI; in which a userindication to unlock access to any category or document via the GUIsends a link to the participating node attempting access to theprotected data via which the protected information is made accessiblefrom the blockchain through a consent management layer of the hostorganization.

According to a particular embodiment, there is a non-transitory computerreadable storage media having instructions stored thereon that, whenexecuted by a system of a host organization having at least a processorand a memory therein, the instructions cause the system to perform thefollowing operations: operating a blockchain interface to a blockchainon behalf of a plurality of tenants of the host organization, in whicheach of the plurality of tenants are participating nodes with theblockchain; receiving a login request from a user device, the loginrequest requesting access to a user profile associated with a first oneof the plurality of tenants; authenticating the user device andretrieving a user profile from the blockchain based on theauthentication of the user device, in which the user profile is storedas a blockchain asset within the blockchain with a first portion of theuser profile including non-protected data accessible to allparticipating nodes on the blockchain and with a second portion of theuser profile including protected data accessible only to participatingnodes having user consent; prompting the user device to grant userconsent to share the protected data with a second one of the pluralityof tenants; and sharing the protected data with the second one of theplurality of tenants by permitting access to the protected data withinthe blockchain asset by the second tenant's participating node.

FIG. 10 shows a diagrammatic representation of a system 1001 withinwhich embodiments may operate, be installed, integrated, or configured.In accordance with one embodiment, there is a system 1001 having atleast a processor 1090 and a memory 1095 therein to execute implementingapplication code 1096 for the methodologies as described herein. Such asystem 1001 may communicatively interface with and cooperatively executewith the benefit of a hosted computing environment, such as a hostorganization, a multi-tenant environment, an on-demand service provider,a cloud based service provider, a client-server environment, etc.

According to the depicted embodiment, the system 1001, which may operatewithin a host organization, includes the processor 1090 and the memory1095 to execute instructions at the system 1001. According to such anembodiment, the processor 1090 is to execute a blockchain servicesinterface 1065 to interface with a blockchain on behalf of a pluralityof tenants of the host organization, in which each of the plurality oftenants are participating nodes 1099 with the blockchain; a receiveinterface 1026 is to receive a login request from a user device 1098,the login request requesting access to a user profile associated with afirst one of the plurality of tenants; an authenticator 1050 toauthenticate the user device 1098 and to retrieve a user profile fromthe blockchain based on the authentication of the user device, in whichthe user profile is stored as a blockchain asset within the blockchainwith a first portion of the user profile including non-protected dataaccessible to all participating nodes on the blockchain and with asecond portion of the user profile including protected data 1040accessible only to participating nodes having user consent; a blockchainconsent manager 1042 to prompt the user device to grant user consent(e.g., element 1041 showing granted consent) to share the protected datawith a second one of the plurality of tenants (e.g., via a GUI 1086transmitted and managed by GUI manager 1085); and a super communitytenant bridge 1043 to share the protected data with the second one ofthe plurality of tenants by permitting access to the protected datawithin the blockchain asset by the second tenant's participating node.

According to another embodiment of the system 1001, the receiveinterface 1026 communicates with a user client device 1098 remote fromthe system and communicatively links the user device with the system viaa public Internet. According to such an embodiment, the system operatesat a host organization as a cloud based service provider to the userdevice 1099; in which the cloud based service provider hosts a receiveinterface 1026 exposed to the user client device via the publicInternet, and further in which the receive interface receives inputsfrom the user device as a request for services from the cloud basedservice provider.

Bus 1016 interfaces the various components of the system 1001 amongsteach other, with any other peripheral(s) of the system 1001, and withexternal components such as external network elements, other machines,client devices, cloud computing services, etc. Communications mayfurther include communicating with external devices via a networkinterface over a LAN, WAN, or the public Internet.

According to such an embodiment, the system may further include thereceive interface to receive a request from the second tenant to createa second user profile; a blockchain services interface to create ablockchain asset including the non-protected information for the seconduser profile; the blockchain services interface to generate a blockchaintransaction including the blockchain asset; the blockchain servicesinterface to broadcast the blockchain transaction into circulation onthe blockchain; and the blockchain services interface to commit thevalidated blockchain transaction in a block to the blockchain.

FIG. 11A depicts another exemplary architecture 1100, with additionaldetail of a blockchain implemented smart contract created utilizing asmartflow contract engine 1105, in accordance with describedembodiments.

In particular, there is depicted here within the host organization theblockchain services interface 190 which now includes the smartflowcontract engine 1105 and additionally includes the GUI manager 1110.

Because blockchain utilizes a distributed ledger, creation and executionof smart contracts can be technically complex, especially for noviceusers. Consequently, a smart flow visual designer allow implementationof smart contracts with greater ease. The resulting smart flow contracthas mathematically verifiable auto-generated code, as created by theblockchain translator 1130 freeing customers and users from having toworry about the programming language used in any given blockchainprotocol. Moreover, the smart flow contract engine implements visualdesigners that coordinate with the blockchain translator 1130 togenerate the requisite native code capable of executing on each of theparticipating nodes of the blockchain, thus further allowing easyprocessing and verification of the smart contract. According to certainembodiments, each smart flow contract utilizes a mathematical code basedverifiable encryption scheme.

Flow designers provide users with a simple, intuitive, web-basedinterface for designing applications and customized process flowsthrough a GUI based guided flow design experience. The flow designerenables even novice users to create otherwise complex functionality,without necessarily having coding expertise or familiarity with theblockchain.

The GUI manager 1110 presents a flow designer GUI 1111 interface to auser device via which users may interact with the host organization. Thesmartflow contract engine 1105 in coordination with the GUI managerinterprets the various rules, conditions, and operations provided by theuser, to generate a smartflow contract which is then translated orwritten into the target blockchain protocol.

Through the flow designer GUI 1111, a user can completely defineutilizing visual flow elements how a particular process, event,agreement, contract, purchase, or some other transaction needs to occur,including dependencies, checks, required process inputs and outputs,triggers, etc.

Using the flow designer GUI 1111, the user simply drags and dropsoperational blocks and defines various conditions and “if then else”events, such as if this event occurs, then take this action. As depictedhere, there are a variety of user defined smart contract blocksincluding user defined conditions 1151, events to monitor 1152, “if”then “else” triggers 1153, and asset identifiers 1154.

Once the user has completed defining the flow including all of itsoperational blocks, conditions, triggers and events, the smartflowcontract engine takes each of the individual blocks and translates theminto a native target blockchain protocol via the blockchain translator1130, and then generates a transaction to write the translated smartflowcontract 1145 into the blockchain 1140 via the blockchain servicesinterface 190.

Once transacted to the blockchain, every participating node with theblockchain will have a copy of the smart contract, and therefore, if anygiven event occurs, the corresponding trigger or rule or condition willbe viewable to all participating nodes, some of which may then take anaction based on the event as defined by the smart contract.

The blockchain services interface 190 of the host organization providescustomers, users, and subscribers access to different blockchains, someof which are managed by the host organization 110, such as privateblockchains, others being public blockchains which are accessiblethrough the host organization 110 which participates as a node on suchpublic blockchains. Regardless, each blockchain utilizes a differentblockchain protocol and has varying rules, configurations, and possiblydifferent languages via which interfaces must use to communicate withthe respective blockchains. Consequently, the blockchain translator 1130depicted here translates the user defined smart contract blocks into thenative or required language and structure of the targeted blockchain1140 onto which the resulting smart contract is to be written ortransacted.

Once the smart contract is transacted and broadcast to the blockchain1145 it is executed within the blockchain and its provisions, as setforth by the user defined smart contract blocks, are then carried outand enforced.

According to one embodiment, a salesforce.com visual flow designer isutilized to generate the user defined smart contract blocks which arethen translated into a blockchain smart contract. According to otherembodiments, different visual flow designers are utilized and theblockchain translator 1130 translates the user defined smart contractblocks into a blockchain smart contract.

The resulting native blockchain protocol smart contract elements 1135may be embodied within a code, structure, or language as dictated by theblockchain 1140 onto which the smart contract is to be written. Forinstance, if the smart contract is to be written to Ethereum then theblockchain translator 113 must translate the user defined smart contractblocks into the Ethereum compliant “Solidity” programming language.Solidity is a contract-oriented, high-level language for implementingsmart contracts specifically on Ethereum. Influenced by C++, Python andJavaScript, the language is designed to target the Ethereum VirtualMachine (EVM). Smart contract elements include support for voting, crowdfunding, blind auctions, multi-signature wallets, as well as many otherfunctions.

Conversely, if the smart contract is to be written to Hyperledger, thenthe language is different, utilizing the Go programming language whichpermits use of a distributed ledger blockchain for and smart contracts,among other capabilities.

While smart contracts are beneficial and supported by many blockchainprotocols they can be cumbersome to implement to the requirement thatthey be programmed in differing languages depending on the particularblockchain being targeted. Therefore, not only must users understandprogramming constructs, but also the particular syntactical nuances ofthe required programming language for the blockchain protocol inquestion.

By utilizing the smart flow contract engine 1105, even novice users cancreate compliant smart contracts by generating the smart contractelements with the flow designer and then leveraging the blockchaintranslator 1130 to actually render the native blockchain programminglanguage code embodying the smart contract elements as defined by theuser, subsequent to which the blockchain services interface 190 handlesthe transacting of the smart contract onto the blockchain.

Consider for example a vendor that sells to Home Depot and wants toexecute a smart contract with Home Depot which uses Ethereum. The vendorlogs in with the host organization, assuming he is an authenticated userand has access to the cloud subscription services, and then accesses thesmartflow contract engine 1105 through which the user may generatewhatever flow he wishes. When done, the user, via the flow designer GUI1111, instructs the blockchain services interface 190 to execute thesmart contract, thus causing the smartflow contract engine to translatethe user's custom designed smartflow contract into Ethereum compliant“Solidity” code, subsequent to which the smartcontract is then writteninto the blockchain for execution. The vendor need not know how toprogram or even understand the details of transacting with theblockchain. Rather, the cloud based services accessible through the hostorganization 110 remove the complexity from the process and present theuser with a simple flow designer GUI 1111 through which all thenecessary operations may thus be carried out.

According to such embodiments, writing the smartcontract to theblockchain requires storing metadata defining the smartcontract in theblockchain as supported by the particular blockchain protocol. Accordingto one embodiment, when a transaction occurs on the blockchain, havingthe metadata for the smart contract therein, the smart contract isexecuted and the various user defined smart contract events, conditions,and operations are then effectuated.

According to certain embodiments, the user defined smartcontract, havingbeen translated and transacted onto the blockchain, triggers events onthe within the host organization.

For example, consider that Wal-Mart and Nestle have an agreement that ashipment must be transported within a climate controlled trailer withina range of 35 to 39 degrees Fahrenheit at all time. Moreover, if thetemperature exceeds 39 degrees at anytime, then the payment isnullified.

Within the host organization, a Customer Relationship Management (CRM)platform defines and manages the various relationships and interactionsbetween customers, vendors, potential customers. suppliers, etc. Theterm CRM is usually in reference to a CRM system, which is a tool thathelps businesses with contact management, sales management, workflowprocesses, productivity and so forth.

In the above example with Wal-Mart and Nestle, the CRM system willpossess the requirements for the shipment. Because the host organizationthrough the CRM system monitors the shipment and subscribes to shipmentevents, such as temperature data, the CRM system will monitor for andbecome aware of a temperature related event for the particular shipmentwhen can then be linked back to the smart contract automatically. Moreparticularly, because the host organization operates as a participatingnode for the blockchain within which the smart contract is executing,the host organization has visibility to both the smart contract termsand conditions accessible via the blockchain and also the CRMrequirements for the shipment, such as the required temperature range.

Therefore, upon the occurrence of a smart contract condition violation,the host organization will synchronize the violation with the CRM system(which is not part of the blockchain) to halt the payment associatedwith that particular shipment, pursuant to the terms of the executingsmart contract.

According to one embodiment, the blockchain sends out an event which theCRM system of the host organization will listen to, and then conductsome substantive action based on the event according to what isspecified by the user defined smart contract flow. With the aboveexample, the substantive action being to halt payment for the shipmentpursuant to the smart contract on the blockchain.

Each of the participating parties for an executing smart contract willlikely have their respective CRM systems subscribed to events of theblockchain associated with the executing smart contract, and therefore,both parties are likely to be aware of the event.

According to one embodiment, logic is written into the CRM system tofacilitate a specific action responsive to a blockchain event. Stateddifferently, non-blockchain actions may be carried out pursuant to anexecuting blockchain smart contract.

FIG. 11B depicts another exemplary architecture 1101, with additionaldetail of a blockchain implemented smart contract created utilizing anApex translation engine 1155, in accordance with described embodiments.

As depicted here, there is an Apex translation engine 1155 within theblockchain services interface 190.

Apex is a programming language provided by the Force.com platform fordevelopers. Apex is similar to Java and C# as it is a strongly typed,object-oriented based language, utilizing a dot-notation andcurly-brackets syntax. Apex can be used to execute programmed functionsduring most processes on the Force.com platform including custom buttonsand links, event handlers on record insertion, update, or deletion, viascheduling, or via the custom controllers of Visualforce pages.

Developers of the salesforce.com host organization utilize Apexfrequently to implement SQL programming, database interactions, customevents for GUI interfaces, report generation, and a multitude of otherfunctions. Consequently, there is a large community of developersassociated with the host organization 110 which are very familiar withApex and prefer to program in the Apex language rather than having toutilize a less familiar programming language.

Problematically, smart contracts must be written in the native languageof the blockchain protocol being targeted for execution of the any smartcontract on the respective blockchain.

For instance, as noted above, if the smart contract is to be written toEthereum then the smart contract must be written with the Ethereumcompliant “Solidity” programming language.

Like the smart contracts, Apex is a kind of a metadata. Therefore, theApex translation engine 1155 permits developers familiar with Apex toprogram their smart contracts for blockchains utilizing the Apexprogramming language rather than utilizing the native smart contractprotocol programming language.

As depicted here, developers write their smart contracts utilizing theApex programming language and then provide the Apex input 1156 to theApex translation engine 1155 via the depicted Apex code interface, forexample, by uploading a text file having the developer's Apex codeembedded therein.

The Apex translation engine 1155 parses the Apex input 1156 to identifythe Apex defined smart contract blocks and breaks them out inpreparation for translation. As despite here, there are Apex definedconditions 1171, Apex events to monitor 1172, “if” then “else” Apextriggers 1173, and as before, asset identifiers 1154 which are not Apexspecific.

The Apex defined smart contract blocks are then provided to the Apexblock translator 1180 which converts them into the native blockchainprotocol smart contract elements 1135 for the targeted blockchainprotocol. Once translated, the process is as described above, in whichthe translated smart contract is transacted and broadcast 1145 to theblockchain 1140 for execution 1145.

Unlike the visual flow GUI, because Apex is programmatic, users writingApex code can write programs to execute on a smart contract and are notlimited by the available functions within the visual flow GUI.

According to a particular embodiment, the Apex input 1156 is firsttranslated into JavaScript and then subsequently translated into aspecific blockchain API appropriate for the targeted blockchain protocolupon which the smart contract is to be executed.

According to another embodiment, listening events may be written usingthe Apex language and provided in the Apex input 1156, however, suchlistening events are to be executed by the host organization. Therefore,the Apex block translator 1180 separates out any identified Apexlisteners 1178 and returns those to the host organization 110 where theymay be implemented within the appropriate CRM system or other eventmonitoring system. In such a way, developers can write the Apex input1156 as a single program and not have to separately create the smartcontract and also the related listening events in separate systems.

FIG. 12 depicts a flow diagram illustrating a method 1200 forimplementing smart flow contracts using distributed ledger technologiesin a cloud based computing environment such as a database systemimplementation supported by a processor and a memory to execute suchfunctionality to provide cloud based on-demand functionality to users,customers, and subscribers.

Method 1200 may be performed by processing logic that may includehardware (e.g., circuitry, dedicated logic, programmable logic,microcode, etc.), software (e.g., instructions run on a processingdevice) to perform various operations such as executing, transmitting,receiving, analyzing, triggering, pushing, recommending, defining,retrieving, parsing, persisting, exposing, loading, operating,generating, storing, maintaining, creating, returning, presenting,interfacing, communicating, querying, processing, providing,determining, displaying, updating, sending, etc., in pursuance of thesystems and methods as described herein. For example, the hostedcomputing environment 111, the blockchain services interface 1120, andits database system 130 as depicted at FIG. 1, et seq., and othersystems and components as described herein may implement the describedmethodologies. Some of the blocks and/or operations listed below areoptional in accordance with certain embodiments. The numbering of theblocks presented is for the sake of clarity and is not intended toprescribe an order of operations in which the various blocks must occur.

With reference to the method 1200 depicted at FIG. 12, at block 1205,processing logic operates a blockchain interface to a blockchain onbehalf of a plurality of tenants of the host organization, wherein eachof the plurality of tenants are participating nodes with the blockchain.

At block 1210, processing logic receives a login request from a userdevice.

At block 1215, processing logic authenticates the user device with thehost organization.

At block 1220, processing logic receives input from the user deviceindicating a plurality of smart contract blocks.

At block 1225, processing logic translates each of the smart contractblocks into a native programming language to form a smart contract toexecute via the blockchain.

At block 1230, processing logic transacts the smart contract onto theblockchain.

According to another embodiment, method 1200 further includes:transmitting a flow designer GUI to the user device; and in whichreceiving the input from the user device includes receiving inputs viathe flow designer GUI indicating user selections of the plurality ofsmart contract blocks with a plurality of flow sequence, flowconditions, flow triggers, and/or flow event operations.

According to another embodiment of method 1200, receiving the input fromthe user device indicating the plurality of smart contract blocksincludes receiving an Apex input file programmed in Apex programminglanguage; in which the method further includes parsing a plurality ofApex defined smart contract blocks from the Apex input file; and inwhich translating each of the smart contract blocks includes translatingthe plurality of parsed Apex defined smart contract blocks into thenative programming language to form the smart contract to execute viathe blockchain.

According to another embodiment of method 1200, translating each of thesmart contract blocks into the native programming language to form asmart contract includes translating each of the plurality of smartcontract blocks into a defined sequence of process operations for thesmart contract, a defined smart contract condition, a defined smartcontract trigger, and/or a defined smart contract event.

According to another embodiment of method 1200, transacting the smartcontract onto the blockchain includes: writing the smart contract intothe blockchain as metadata via a blockchain services interface of thehost organization; and in which the smart contract executes via theblockchain for one or more transactions occurring on the blockchain.

According to another embodiment, method 1200 further includes:extracting an event listener from the input received from the user, inwhich the event listener monitors the blockchain transactions fordefined events having a corresponding smart contract condition or smartcontract trigger within the smart contract transacted onto theblockchain; and executing the event listener separate from theblockchain, in which the event listener executes within the hostorganization and triggers a pre-programmed action within the hostorganization upon occurrence of the event within a transaction on theblockchain.

According to another embodiment of method 1200, the event listenerexecutes within a Customer Relationship Management (CRM) platform of thehost organization on behalf of a tenant of the host organization whichis a participating party to the smart contract executing on theblockchain; and in which executing the event includes one of: halting apayment via the CRM system pursuant to a violation of terms orconditions defined by the smart contract executing within the blockchainor authorizing payment via the CRM system pursuant to fulfillment of allterms and conditions defined by the smart contract executing within theblockchain.

According to another embodiment of method 1200, translating each of thesmart contract blocks into a native programming language to form a smartcontract to execute via the blockchain, includes: translating each ofthe smart contract blocks into an Ethereum compliant Solidityprogramming language; in which the host organization operates aparticipating node on an Ethereum blockchain via a blockchain servicesinterface of the host organization; and in which transacting the smartcontract onto the blockchain includes transacting the smart contractonto the Ethereum blockchain via the participating node for executionvia the Ethereum blockchain.

According to another embodiment of method 1200, translating each of thesmart contract blocks into a native programming language to form a smartcontract to execute via the blockchain, includes: translating each ofthe smart contract blocks into a Hyperledger compliant Go programminglanguage; in which the host organization operates a participating nodeon a Hyperledger blockchain via a blockchain services interface of thehost organization; and in which transacting the smart contract onto theblockchain includes transacting the smart contract onto the Hyperledgerblockchain via the participating node for execution via the Hyperledgerblockchain.

According to another embodiment of method 1200, receiving the input fromthe user device indicating a plurality of smart contract blocksincludes: transmitting a flow designer GUI from a GUI manager of thehost organization to the user device for display at the user device; andreceiving mouse movement events at the flow designer GUI displayed tothe user device indicating drag and drop selections and sequencing ofavailable smart contract conditions, triggers, and events available viathe flow designer GUI.

FIG. 13 shows a diagrammatic representation of a system 1301 withinwhich embodiments may operate, be installed, integrated, or configured.In accordance with one embodiment, there is a system 1301 having atleast a processor 1390 and a memory 1395 therein to execute implementingapplication code 1396 for the methodologies as described herein. Such asystem 1301 may communicatively interface with and cooperatively executewith the benefit of a hosted computing environment, such as a hostorganization, a multi-tenant environment, an on-demand service provider,a cloud based service provider, a client-server environment, etc.

According to the depicted embodiment, the system 1301, which may operatewithin a host organization, includes the processor 1390 and the memory1395 to execute instructions at the system 1301. According to such anembodiment, the processor 1390 is to execute a blockchain servicesinterface 1365 to interface with a blockchain on behalf of a pluralityof tenants of the host organization, in which each of the plurality oftenants are participating nodes 1399 with the blockchain; a receiveinterface 1326 is to receive a login request from a user device 1398.According to such an embodiment, there is an authenticator 1350 toauthenticate the user device 1398 with the host organization. Thereceive interface 1326 to further receive input 1327 from the userdevice 1398 indicating a plurality of smart contract blocks; atranslator (and parser) 1343 is to translate each of the smart contractblocks into a native programming language on behalf of a smartflowcontract engine so as to form a smart contract 1340 to execute via theblockchain. The blockchain services interface 1365 is then to transactthe smart contract 1340 onto the blockchain.

According to another embodiment of system 1301, the system furtherincludes a GUI manager 1385 to transmit a flow designer GUI 1341 to theuser device; and in which the receive interface is to receive inputs1327 via the flow designer GUI indicating user selections of theplurality of smart contract blocks 1386 with a plurality of flowsequence, flow conditions, flow triggers, and/or flow event operations.

According to another embodiment of the system 1301, the receiveinterface 1326 communicates with a user client device 1398 remote fromthe system and communicatively links the user device with the system viaa public Internet. According to such an embodiment, the system operatesat a host organization as a cloud based service provider to the userdevice 1399; in which the cloud based service provider hosts a receiveinterface 1326 exposed to the user client device via the publicInternet, and further in which the receive interface receives inputsfrom the user device as a request for services from the cloud basedservice provider.

Bus 1316 interfaces the various components of the system 1301 amongsteach other, with any other peripheral(s) of the system 1301, and withexternal components such as external network elements, other machines,client devices, cloud computing services, etc. Communications mayfurther include communicating with external devices via a networkinterface over a LAN, WAN, or the public Internet.

According to a particular embedment, there is a non-transitory computerreadable storage media having instructions stored thereon that, whenexecuted by a system of a host organization having at least a processorand a memory therein, the instructions cause the system to perform thefollowing operations: operating a blockchain interface to a blockchainon behalf of a plurality of tenants of the host organization, in whicheach of the plurality of tenants are participating nodes with theblockchain; receiving a login request from a user device; authenticatingthe user device with the host organization; receiving input from theuser device indicating a plurality of smart contract blocks; translatingeach of the smart contract blocks into a native programming language toform a smart contract to execute via the blockchain; and transacting thesmart contract onto the blockchain.

FIG. 14 depicts another exemplary architecture 1400, with additionaldetail of a virtual chain model utilized to interface with fordistributed ledger technologies via a cloud based computing environment,in accordance with described embodiments.

Depicted here is the host organization and its various elements asdescribed previously, however, there is further depicted a virtual chaininterface 1405 within the blockchain services interface 190 whichprovides an alternative programmatic interface to support blockchainprotocol implementations, be they public blockchains upon which the hostorganization operates as a participating node, or public blockchainprotocol implementations provided by the host organization 110 orprivate blockchains provided by the host organization 110.

Developers utilizing distributed ledger technologies to interface withprivate and public blockchains conventionally were required to utilizethe native programming language of those blockchains, rather than havingthe ability to utilize the programming language of their own choosing.This requirement creates some difficulty for developers who may berequired to program using languages with which they have far lessfamiliarity, thus inhibiting use of blockchain technologies.

Within the host organization 110, it is very common for developers tointeract with the database system 130 via the query interface 180utilizing a structured query language, such as SQL or PL/SOQL.

It is therefore in a accordance with the described embodiments that thehost organization 110 provides the ability to interact with a blockchainthrough the virtual chain interface 1405 utilizing syntax similar to anormal SQL query ordinarily utilized to query a relational database.

As depicted here, the virtual chain interface 1405 is able to receive astructured query 1406 from a user targeting the blockchain and thenroute the structured query 1406 through a query parser 1425 which breaksdown the elements of the structured query 1406. For instance, the queryparser 1425 as depicted here breaks down the structured query 1406 intoblockchain update logic 1421, blockchain read logic 1422, blockchaindelete logic 1423 (e.g., equivalent to removing a row from a database),and blockchain search logic 1424, resulting in the identified queryelements being parsed from the structured query received at the virtualchain interface 1405 from the user.

The identified query elements are then mapped to corresponding nativeblockchain functions, code, or logic by the query logic translator 1430so as to result in native blockchain protocol code 1435 constituting theequivalent functionality of the structured query 1406 and thus resultingin the native blockchain transaction 1445 which is then transacted ontothe blockchain 1440 triggering the return of the transaction result tothe virtual chain interface.

According to one embodiment, the virtual chain interface 1405 provides avirtual table or a list of entries and conversions which mimic theblockchain, thus permitting a mapping, conversion, or translation ofoperational elements within the structured query 1406 to be replacedwith native blockchain code or functions, based on the virtual table.

Once the functional elements are converted from the incoming structuredquery into the native blockchain functions, the resulting nativeblockchain transaction is simply executed via the blockchain, forinstance, by broadcasting the transaction, writing the transaction intoa block of the blockchain, validating the block, and then committing thevalidated block to the blockchain.

According to one embodiment, the structured query 1406 received at thevirtual chain interface is written using standard SQL syntax, however,behind the scenes and invisible to the user, the virtual chain interface1405 identifies the contextually relevant information based on the userand the structured query elements utilized to generate a properly formedtransaction for the blockchain.

Consider for instance a received structured query 1406 which provides anSQL INSERT statement. Normally, the syntax would be INSERT INTOtable_name (column1, column2, column3, . . . ), however, the virtualchain interface will translate the INSERT command into an appropriatenative blockchain command. The commands are different depending on theblockchain protocol and interface script being utilized, but one suchcommand to insert data onto a blockchain is OP_RETURN <the data you wantto add> and therefore, the INSERT is converted to an OP_RETURN the INTOis converted into a targeted location such as metadata, contracts,blockchain asset, etc., which may be identified automatically by thevirtual chain interface's understanding of the user's context submittingthe structured query as the submitter will be associated with specificblockchain elements.

Similarly, if the user presents a structured query 1406 specifying anUPDATE command, then it is necessary to convert the UPDATE command intoa relevant command for the blockchain since the immutable nature of theblockchain means that no accepted block in the chain can ever bemodified. Consequently, an UPDATE command of a structured query 1406must be converted to an add. Therefore, where a user specifies, forexample, UPDATE table_name, SET column1=value1, column2=value2, . . . ,WHERE condition, the virtual chain interface will translate the incomingstructured query elements into an insert block command as well aspopulate the necessary user management, including, for example, addingthe necessary user keys and any other formalities required to transactwith the blockchain.

For example, while the host organization operates as node on theblockchain and therefore has access to data within the blockchain, it isnecessary for blockchain transactions to be performed from theappropriate participating node where data is being added or modified(e.g., via a new add which supersedes old data). Therefore, the virtualchain interface additionally maps the user ID or requestor of thestructured query 1406 to a participating node and transacts the nativeblockchain transaction from a participating node corresponding to theuser ID or the requestor of the incoming structured query 1406.

Similarly, where a user specifies via the structured query a SELECT FROMcommand, such as specifying, SELECT column1, column2, . . . FROMtable_name, then the virtual chain interface will attain translate thequery elements to the appropriate blockchain native protocol coderequired to retrieve data from the blockchain, including translating ormapping the table_name field to an appropriate blockchain asset,metadata, or other readable storage location. For instance, if thestructured query specifies an object, then the virtual chain interfacewill translate the target object name to the corresponding blockchainasset from which the blockchain's payload data may then be read andreturned in reply to the structured query.

From a user or customer perspective, structured queries may thus beprogrammed within applications, reports, and ad-hoc targeting aspecified blockchain distributed ledger for which the user or customerhas a participating node, and the virtual chain interface willtransparently handle the conversion of the structured query to therequisite native blockchain protocol code 1435 without requiring furtherinvolvement or technical know-how from the user.

According to described embodiments, each tenant of the host organizationhaving data stored within a specified blockchain will have at least oneparticipating node with the blockchain, however, certain tenants of thehost organization may have multiple participating nodes on a singleblockchain.

For example, a tenant of the host organization having multiple differentproducts or product lines may elect to have distinct participating nodeswith the blockchain for each product or product line, and therefore, the“table_name” referenced by a structured query is mapped to theappropriate participating node and blockchain asset for the tenant,where more than one exists. In another embodiment, a single tenant ofthe host organization may have multiple customer organizations, andtherefore, such a tenant may organize each customer organization intoits own participating node with the blockchain, in which case thevirtual chain interface will map the designated table name or objectwithin a structured query 1406 to a participating node with theblockchain based on the OrgID for the tenant being used to submit thestructured query.

In other embodiments, a single tenant may utilize multiple differentblockchains, and therefore, the virtual chain interface needs to map thespecified table name or object to a targeted blockchain, as well as tothe participating node and blockchain asset with the targetedblockchain. Consider for example Walmart as a tenant of the hostorganization which utilizes a financial private blockchain to storefinancial related information and utilizes a different blockchain, suchas a private shipping blockchain, to store supply chain data. In such anevent, Walmart would be a participating on each of the financial privateblockchain and the private shipping blockchain, and thus, Walmart wouldhave at least those two participating nodes. Consequently, the virtualchain interface must map any specified table name or storage locationspecified by a SQL command to the appropriate blockchain and theparticipating node and blockchain asset with the targeted blockchain.

In such a way, users, customer organizations, and tenants can issuecommands such as “SELECT FROM” this “OBJECT” or “INSERT BLOCK” or“UPDATE BLOCK” without having to understand the native blockchainprotocol code as the translation is handled by the virtual chaininterface 1405 on behalf of the user. Moreover, because the user isauthenticated with the host organization, the virtual chain interfacealso handles all the backend administration required to transact withthe blockchain, such as providing and automatically populating therequisite asset ID, etc.

Upon the very first transaction, the virtual chain interface will needto perform an insert command into the blockchain to create a newparticipating node, however, once created, the existing participant maybe used from then forward as the entries within the blockchain are neverremoved. For instance, if the user has never conducted a transaction onthe target blockchain, then the virtual chain interface will handle theadministrative tasks to create a participant in the blockchain based onthat user's credentials and then generate a key for that user for usewith the blockchain, as all transactions are based on the key. Oncecomplete, then the virtual chain interface will translate the structuredquery into a statement referred to as the asset payload of blockchainbased on the mapping.

According to certain embodiments, the virtual chain interfaceadditionally handles synchronization with the blockchain, for instance,recognizing the difference between pending transactions on theblockchain for which consensus has not yet been reached versus thosevalidated transactions having consensus may therefore be considered ascommitted transactions to the blockchain. For example, where a pendingtransaction is submitted but never reaches consensus the virtual chaininterface will handle the equivalent of a rollback transaction. In SQL,a “ROLLBACK” is a command that causes all data changes since the lastBEGIN WORK or START TRANSACTION to be discarded by the relationaldatabase management systems (RDBMS), so that the state of the data is“rolled back” to the way it was before those changes were made.Similarly, a transaction broadcast to the blockchain participating nodeswhich is written to a block which is subsequently invalidated,truncated, or ignored, in favor of a different block (e.g., on the basisof consensus, proof of work, etc.) will result in the broadcasttransaction being effectively nullified, and thus, the virtual chaininterface 1405 tracks the status and reflects such a failed condition soas to maintain synchronization between the blockchain and the structuredquery requestor.

For instance, information is returned to the user submitting astructured query that the query reads from, updates, or in some wayaffects a pending transaction. Upon submitting such a query, the userwill be presented with information indicating that the transaction asbeen posted but is on pending commit.

Once the transaction is committed into the blockchain, only then willthe user see that it can be retrieved as a committed transaction versusbeing retrievable only as a pending/non-committed transaction.

The virtual chain interface 1405 additionally supports smart contractingwith the blockchain such that if a defined event occurs within atransaction on the blockchain, then the entire smart contract will beexecuted via the blockchain. The virtual chain interface 1405 willautomatically listen to specified events and then perform pre-definedactions when those events are observed to occur on the blockchain.

Consider for example the SQL SELECT FROM statement, which isincompatible with the available blockchain protocols. For instance,where a structured query specifies to SELECT a, b, c FROM, financialaccount_B, then the “B” will be interpreted as an identifier within theblockchain. Similarly, a modified dot notation may be utilized, suchspecifying SELECT “ID” FROM blockchain_financial account_B will thusinterpret the leading “blockchain” as the targeted blockchain to beutilized, with the virtual chain interface identifying the appropriateparticipating node, and the “B” being interpreted as an identifier withthe specified blockchain, in which the identifier represents a specificpayload within the blockchain from which to retrieve the data.

The virtual chain interface 1405 additionally maintains its mapping bypulling the latest transaction from the blockchain or the latest blockfrom the blockchain for that specific customer across all assets withinthe blockchain.

According to another embodiment, the virtual chain interface 1405supports retrieval of historical data from the blockchain. For example,for an entity specifying financial_account_history_b, the virtual chaininterface 1405 will generate native blockchain protocol code to pull alltransactions that have ever happened within the specified blockchain forthat specified asset, thus returning a series of transactions that haveoccurred over time. Unlike a database which may overwrite the data aftera committed update, the blockchain never discards the information, andtherefore, the latest current information may be retrieved or thecomplete historical information may also be retrieved.

Consider for example, a transaction to add a customer in which the firsttransaction specifies the customer's first and last name, but is missingthe SSN. Then a second transaction specifies the SSN which is added tothe blockchain. Then a third transaction updates the contact informationfor the customer. A fourth transaction then changes the customer's phonenumber. All of these transactions are applied the same customer asset,however, all four are distinct transactions with the blockchain.Consequently, a structured query may specify SELECT a, b, c fromcustomer_b. in which will result in the latest most up to dateinformation being returned for that customer. However, if instead thestructured query specifies SELECT a, b, c from customer_history_b, thenthe virtual chain interface 1405 will retrieve the entire historicalrecord of all changes to the customer_b, such that it may be viewablethat the initial entry pursuant to a first transaction was missing SSNand that a fourth transaction resulted in the change to the customer'stelephone number, ultimately ending with the latest most up to dateinformation for that blockchain asset.

According to certain embodiments, the virtual chain interface 1405handles all mapping automatically between the parsed structured queryelements and the native blockchain protocol code, however, inalternative embodiments, the customer may provide mappings from thecustomer's information, table names, variables, participant ID, andquery elements to the corresponding native blockchain protocol code 1435elements.

For example, the customer may store data within table “X” within thehost organization, but when it is going into blockchain, it is mapped toX+Y, which may be user specified. Therefore, the virtual chain interfacewill map the SQL-type commands to the blockchain data which is calledX+Y based on the customer provided mapping. Such mappings may be storedas metadata on behalf of the customer, for instance, within aconfiguration file which is read by the virtual chain interface.

The customer may have data in the blockchain called ABC, and then wish,for whatever reason, to change the data to A1B1C1. The customer canspecify such a mapping and the virtual chain interface will thenautomatically generate an add asset transaction in the blockchain andput the transaction pending for the user so that the user knows that thetransaction is in a pending state and not committed until consensus isreached and sufficient mining has occurred such that the transaction iscommitted to the blockchain.

Once committed, an event is triggered from blockchain which the hostorganization's blockchain services interface 190 listens for, at whichpoint the host organization also marks the data as committed, so as tokeep the data status synchronized.

Also possible is that consensus is never reached and therefore thetransaction fails. Again, the host organization's blockchain servicesinterface 190 listens for the event indicating failure of thetransaction, at which point the host organization marks the transactionas failed and the virtual chain interface performs any necessaryrollback operation so as to maintain synchronization.

It is also feasible that some other participating node adds updatedinformation to the blockchain superseding old data for an asset. Whenthe data is refreshed by any participating node, including being read bythe virtual chain interface pursuant to a structured query requestingthe data to be retrieved, the latest value will be retrieved, regardlessof what entity updated the value. Because the data is stored within adistributed ledger, any participating node specifying the correct keymay submit a transaction to update the blockchain asset according tosuch an embodiment.

According to another embodiment, the host organization's blockchainservices interface 190 listens for any event or change to specifiedblockchain assets, upon which an event will be triggered, such that auser requesting notification pertaining to changes to a specified assetwill be notified by the host organization, without having to go andretrieve the data to and check to determine if changes have been made.

For instance, as part of the transaction management performed by thevirtual chain interface, whenever an asset is created in the blockchain,the blockchain services interface 190 keeps the blockchain asset ID withthe Salesforce ID together so that commit and non-commit status can betracked. Therefore, the blockchain asset ID with the Salesforce ID forthat particular asset can also be monitored for any changes by anotherentity.

According to certain embodiments, the data within the blockchain assetis available within the host organization via the participating node ofthe host organization, and therefore, the latest copy is alwaysavailable to the host organization from the distributed ledger, assumingthe data has been committed.

According to one embodiment, a user that authenticates with the hostorganization will result in the virtual chain interface contextuallymapping that user's host organization identifier to a cryptographic IDutilized by the blockchain. In such a way, the user need not know orprovide the cryptographic ID as it will be supplied for all transactionsby the virtual chain interface 1405.

FIG. 15 depicts a flow diagram illustrating a method 1500 forimplementing a virtual chain model for distributed ledger technologiesin a cloud based computing environment such as a database systemimplementation supported by a processor and a memory to execute suchfunctionality to provide cloud based on-demand functionality to users,customers, and subscribers.

Method 1500 may be performed by processing logic that may includehardware (e.g., circuitry, dedicated logic, programmable logic,microcode, etc.), software (e.g., instructions run on a processingdevice) to perform various operations such as executing, transmitting,receiving, analyzing, triggering, pushing, recommending, defining,retrieving, parsing, persisting, exposing, loading, operating,generating, storing, maintaining, creating, returning, presenting,interfacing, communicating, querying, processing, providing,determining, displaying, updating, sending, etc., in pursuance of thesystems and methods as described herein. For example, the hostedcomputing environment 111, the blockchain services interface 1150, andits database system 130 as depicted at FIG. 1, et seq., and othersystems and components as described herein may implement the describedmethodologies. Some of the blocks and/or operations listed below areoptional in accordance with certain embodiments. The numbering of theblocks presented is for the sake of clarity and is not intended toprescribe an order of operations in which the various blocks must occur.

With reference to the method 1500 depicted at FIG. 15, at block 1505,processing logic operates a blockchain interface to a blockchain onbehalf of a plurality of tenants of the host organization, wherein eachof the plurality of tenants are participating nodes with the blockchain.

At block 1510, processing logic receives a login request from a userdevice.

At block 1515, processing logic authenticates the user device with thehost organization.

At block 1520, processing logic correlates the authenticated user devicewith a cryptographic ID for the blockchain corresponding to theauthenticated user device.

At block 1525, processing logic receives a structured query from theuser device to be executed against the blockchain, the structured queryspecifying a transaction command and a data object upon which thetransaction command is to be performed.

At block 1530, processing logic translates the transaction command ofthe structured query to native blockchain protocol code and translatingthe data object to a blockchain asset ID stored within the blockchain toform a native blockchain transaction.

At block 1535, processing logic executes the native blockchaintransaction with the blockchain.

According to another embodiment of method 1500, the data objectspecified via the structured query is specified via a host organizationobject ID; and in which translating the data object to a blockchainasset ID includes translating the host organization object ID to theblockchain asset ID based on a 1:1 mapping maintained by a virtual chaininterface of the host organization.

According to another embodiment of method 1500, correlating theauthenticated user device with the cryptographic ID for the blockchaincorresponding to the authenticated user device includes identifying thecryptographic ID for the blockchain based on a userID utilized toauthenticate the user device with the host organization or based on acustomer organization ID (OrgID) contextually associated with theauthenticated user device, in which the user device is an authenticatedmember of the customer organization associated with the OrgID.

According to another embodiment, method 1500 further includes: parsing aplurality of query elements from the structured query via a query parserto identify query elements; and translating the parsed query elements tonative blockchain protocol code via a query logic translator to form thenative blockchain transaction.

According to another embodiment of method 1500, the native blockchaintransaction specifies the cryptographic ID, the blockchain asset IDstored within the blockchain, and data to be added or retrieved from thepayload of the asset ID based on the structured query received from theuser device.

According to another embodiment of method 1500, executing the nativeblockchain transaction with the blockchain includes executing anasynchronous transaction via the blockchain; and tracking status of thenative blockchain transaction to determine whether the native blockchaintransaction is pending, committed, or failed.

According to another embodiment, method 1500 further includes:maintaining both the blockchain asset ID with a host organization objectID corresponding to the data object specified via the structured queryand tracking the status of the native blockchain transaction based onthe blockchain asset ID by subscribing to any events within theblockchain associated with the blockchain asset ID; receiving an eventfrom the blockchain associated with the blockchain asset ID; correlatingthe blockchain asset ID to the host organization object ID; andnotifying the user device of the event, in which the event specifies oneof (i) the native blockchain transaction remains pending, (ii) thenative blockchain transaction is committed to the blockchain, or (iii)the native blockchain transaction has failed.

According to another embodiment, method 1500 further includes:determining the native blockchain transaction has failed and performinga rollback procedure for the native blockchain transaction includingnotifying the user device that the native blockchain transaction hasfailed.

According to another embodiment of method 1500, the structured queryfrom the user device corresponds to a blockchain asset for which a priortransaction remains in a pending and non-committed state; and indicatingto the user device that the blockchain asset addressed by the structuredquery is subject to the prior transaction which remains in the pendingand non-committed state.

According to another embodiment of method 1500, the structured queryspecifies one of a SELECT command term, an UPDATE command term, or anINSERT command term; and in which translating the transaction command ofthe structured query includes translating the SELECT command term, theUPDATE command term, or the INSERT command term into a native commandterm compliant with the blockchain.

According to a particular embodiment, there is non-transitory computerreadable storage media having instructions stored thereon that, whenexecuted by a system of a host organization having at least a processorand a memory therein, the instructions cause the system to perform thefollowing operations: operating a blockchain interface to a blockchainon behalf of a plurality of tenants of the host organization, in whicheach of the plurality of tenants are participating nodes with theblockchain; receiving a login request from a user device; authenticatingthe user device with the host organization; correlating theauthenticated user device with a cryptographic ID for the blockchaincorresponding to the authenticated user device; receiving a structuredquery from the user device to be executed against the blockchain, thestructured query specifying a transaction command and a data object uponwhich the transaction command is to be performed; translating thetransaction command of the structured query to native blockchainprotocol code and translating the data object to a blockchain asset IDstored within the blockchain to form a native blockchain transaction;and executing the native blockchain transaction with the blockchain.

According to another embodiment, there is a system to execute at a hostorganization, in which the system includes: a memory to storeinstructions; a processor to execute instructions; in which theprocessor is to execute a blockchain interface to a blockchain on behalfof a plurality of tenants of the host organization, in which each of theplurality of tenants are participating nodes with the blockchain; areceive interface to receive a login request from a user device; anauthenticator to authenticate the user device with the hostorganization; a virtual chain interface correlate the authenticated userdevice with a cryptographic ID for the blockchain corresponding to theauthenticated user device; the receive interface to receive a structuredquery from the user device to be executed against the blockchain, thestructured query specifying a transaction command and a data object uponwhich the transaction command is to be performed; a query logictranslator to translate the transaction command of the structured queryto native blockchain protocol code and translating the data object to ablockchain asset ID stored within the blockchain to form a nativeblockchain transaction; and a blockchain services interface to executethe native blockchain transaction with the blockchain.

FIG. 16A illustrates a block diagram of an environment 1698 in which anon-demand database service may operate in accordance with the describedembodiments. Environment 1698 may include user systems 1612, network1614, system 1616, processor system 1617, application platform 1618,network interface 1620, tenant data storage 1622, system data storage1624, program code 1626, and process space 1628. In other embodiments,environment 1698 may not have all of the components listed and/or mayhave other elements instead of, or in addition to, those listed above.

Environment 1698 is an environment in which an on-demand databaseservice exists. User system 1612 may be any machine or system that isused by a user to access a database user system. For example, any ofuser systems 1612 can be a handheld computing device, a mobile phone, alaptop computer, a work station, and/or a network of computing devices.As illustrated in FIG. 16A (and in more detail in FIG. 16B) user systems1612 might interact via a network 1614 with an on-demand databaseservice, which is system 1616.

An on-demand database service, such as system 1616, is a database systemthat is made available to outside users that do not need to necessarilybe concerned with building and/or maintaining the database system, butinstead may be available for their use when the users need the databasesystem (e.g., on the demand of the users). Some on-demand databaseservices may store information from one or more tenants stored intotables of a common database image to form a multi-tenant database system(MTS). Accordingly, “on-demand database service 1616” and “system 1616”is used interchangeably herein. A database image may include one or moredatabase objects. A relational database management system (RDMS) or theequivalent may execute storage and retrieval of information against thedatabase object(s). Application platform 1618 may be a framework thatallows the applications of system 1616 to run, such as the hardwareand/or software, e.g., the operating system. In an embodiment, on-demanddatabase service 1616 may include an application platform 1618 thatenables creation, managing and executing one or more applicationsdeveloped by the provider of the on-demand database service, usersaccessing the on-demand database service via user systems 1612, or thirdparty application developers accessing the on-demand database servicevia user systems 1612.

The users of user systems 1612 may differ in their respectivecapacities, and the capacity of a particular user system 1612 might beentirely determined by permissions (permission levels) for the currentuser. For example, where a salesperson is using a particular user system1612 to interact with system 1616, that user system has the capacitiesallotted to that salesperson. However, while an administrator is usingthat user system to interact with system 1616, that user system has thecapacities allotted to that administrator. In systems with ahierarchical role model, users at one permission level may have accessto applications, data, and database information accessible by a lowerpermission level user, but may not have access to certain applications,database information, and data accessible by a user at a higherpermission level. Thus, different users will have different capabilitieswith regard to accessing and modifying application and databaseinformation, depending on a user's security or permission level.

Network 1614 is any network or combination of networks of devices thatcommunicate with one another. For example, network 1614 can be any oneor any combination of a LAN (local area network), WAN (wide areanetwork), telephone network, wireless network, point-to-point network,star network, token ring network, hub network, or other appropriateconfiguration. As the most common type of computer network in currentuse is a TCP/IP (Transfer Control Protocol and Internet Protocol)network, such as the global internetwork of networks often referred toas the “Internet” with a capital “I,” that network will be used in manyof the examples herein. However, it is understood that the networks thatthe claimed embodiments may utilize are not so limited, although TCP/IPis a frequently implemented protocol.

User systems 1612 might communicate with system 1616 using TCP/IP and,at a higher network level, use other common Internet protocols tocommunicate, such as HTTP, FTP, AFS, WAP, etc. In an example where HTTPis used, user system 1612 might include an HTTP client commonly referredto as a “browser” for sending and receiving HTTP messages to and from anHTTP server at system 1616. Such an HTTP server might be implemented asthe sole network interface between system 1616 and network 1614, butother techniques might be used as well or instead. In someimplementations, the interface between system 1616 and network 1614includes load sharing functionality, such as round-robin HTTP requestdistributors to balance loads and distribute incoming HTTP requestsevenly over a plurality of servers. At least as for the users that areaccessing that server, each of the plurality of servers has access tothe MTS' data; however, other alternative configurations may be usedinstead.

In one embodiment, system 1616, shown in FIG. 16A, implements aweb-based customer relationship management (CRM) system. For example, inone embodiment, system 1616 includes application servers configured toimplement and execute CRM software applications as well as providerelated data, code, forms, webpages and other information to and fromuser systems 1612 and to store to, and retrieve from, a database systemrelated data, objects, and Webpage content. With a multi-tenant system,data for multiple tenants may be stored in the same physical databaseobject, however, tenant data typically is arranged so that data of onetenant is kept logically separate from that of other tenants so that onetenant does not have access to another tenant's data, unless such datais expressly shared. In certain embodiments, system 1616 implementsapplications other than, or in addition to, a CRM application. Forexample, system 1616 may provide tenant access to multiple hosted(standard and custom) applications, including a CRM application. User(or third party developer) applications, which may or may not includeCRM, may be supported by the application platform 1618, which managescreation, storage of the applications into one or more database objectsand executing of the applications in a virtual machine in the processspace of the system 1616.

One arrangement for elements of system 1616 is shown in FIG. 16A,including a network interface 1620, application platform 1618, tenantdata storage 1622 for tenant data 1623, system data storage 1624 forsystem data 1625 accessible to system 1616 and possibly multipletenants, program code 1626 for implementing various functions of system1616, and a process space 1628 for executing MTS system processes andtenant-specific processes, such as running applications as part of anapplication hosting service. Additional processes that may execute onsystem 1616 include database indexing processes.

Several elements in the system shown in FIG. 16A include conventional,well-known elements that are explained only briefly here. For example,each user system 1612 may include a desktop personal computer,workstation, laptop, PDA, cell phone, or any wireless access protocol(WAP) enabled device or any other computing device capable ofinterfacing directly or indirectly to the Internet or other networkconnection. User system 1612 typically runs an HTTP client, e.g., abrowsing program, such as Microsoft's Internet Explorer browser, aMozilla or Firefox browser, an Opera, or a WAP-enabled browser in thecase of a smartphone, tablet, PDA or other wireless device, or the like,allowing a user (e.g., subscriber of the multi-tenant database system)of user system 1612 to access, process and view information, pages andapplications available to it from system 1616 over network 1614. Eachuser system 1612 also typically includes one or more user interfacedevices, such as a keyboard, a mouse, trackball, touch pad, touchscreen, pen or the like, for interacting with a graphical user interface(GUI) provided by the browser on a display (e.g., a monitor screen, LCDdisplay, etc.) in conjunction with pages, forms, applications and otherinformation provided by system 1616 or other systems or servers. Forexample, the user interface device can be used to access data andapplications hosted by system 1616, and to perform searches on storeddata, and otherwise allow a user to interact with various GUI pages thatmay be presented to a user. As discussed above, embodiments are suitablefor use with the Internet, which refers to a specific globalinternetwork of networks. However, it is understood that other networkscan be used instead of the Internet, such as an intranet, an extranet, avirtual private network (VPN), a non-TCP/IP based network, any LAN orWAN or the like.

According to one embodiment, each user system 1612 and all of itscomponents are operator configurable using applications, such as abrowser, including computer code run using a central processing unitsuch as an Intel Pentium® processor or the like. Similarly, system 1616(and additional instances of an MTS, where more than one is present) andall of their components might be operator configurable usingapplication(s) including computer code to run using a central processingunit such as processor system 1617, which may include an Intel Pentium®processor or the like, and/or multiple processor units.

According to one embodiment, each system 1616 is configured to providewebpages, forms, applications, data and media content to user (client)systems 1612 to support the access by user systems 1612 as tenants ofsystem 1616. As such, system 1616 provides security mechanisms to keepeach tenant's data separate unless the data is shared. If more than oneMTS is used, they may be located in close proximity to one another(e.g., in a server farm located in a single building or campus), or theymay be distributed at locations remote from one another (e.g., one ormore servers located in city A and one or more servers located in cityB). As used herein, each MTS may include one or more logically and/orphysically connected servers distributed locally or across one or moregeographic locations. Additionally, the term “server” is meant toinclude a computer system, including processing hardware and processspace(s), and an associated storage system and database application(e.g., OODBMS or RDBMS) as is well known in the art. It is understoodthat “server system” and “server” are often used interchangeably herein.Similarly, the database object described herein can be implemented assingle databases, a distributed database, a collection of distributeddatabases, a database with redundant online or offline backups or otherredundancies, etc., and might include a distributed database or storagenetwork and associated processing intelligence.

FIG. 16B illustrates another block diagram of an embodiment of elementsof FIG. 16A and various possible interconnections between such elementsin accordance with the described embodiments. FIG. 16B also illustratesenvironment 1699. However, in FIG. 16B, the elements of system 1616 andvarious interconnections in an embodiment are illustrated in furtherdetail. More particularly, FIG. 16B shows that user system 1612 mayinclude a processor system 1612A, memory system 1612B, input system1612C, and output system 1612D. FIG. 16B shows network 1614 and system1616. FIG. 16B also shows that system 1616 may include tenant datastorage 1622, having therein tenant data 1623, which includes, forexample, tenant storage space 1627, tenant data 1629, and applicationmetadata 1631. System data storage 1624 is depicted as having thereinsystem data 1625. Further depicted within the expanded detail ofapplication servers 1600 _(1-N) are User Interface (UI) 1630,Application Program Interface (API) 1632, application platform 1618includes PL/SOQL 1634, save routines 1636, application setup mechanism1638, process space 1628 includes system process space 1602, tenant 1-Nprocess spaces 1604, and tenant management process space 1610. In otherembodiments, environment 1699 may not have the same elements as thoselisted above and/or may have other elements instead of, or in additionto, those listed above.

User system 1612, network 1614, system 1616, tenant data storage 1622,and system data storage 1624 were discussed above in FIG. 16A. As shownby FIG. 16B, system 1616 may include a network interface 1620 (of FIG.16A) implemented as a set of HTTP application servers 1600, anapplication platform 1618, tenant data storage 1622, and system datastorage 1624. Also shown is system process space 1602, includingindividual tenant process spaces 1604 and a tenant management processspace 1610. Each application server 1600 may be configured to tenantdata storage 1622 and the tenant data 1623 therein, and system datastorage 1624 and the system data 1625 therein to serve requests of usersystems 1612. The tenant data 1623 might be divided into individualtenant storage areas (e.g., tenant storage space 1627), which can beeither a physical arrangement and/or a logical arrangement of data.Within each tenant storage space 1627, tenant data 1629, and applicationmetadata 1631 might be similarly allocated for each user. For example, acopy of a user's most recently used (MRU) items might be stored totenant data 1629. Similarly, a copy of MRU items for an entireorganization that is a tenant might be stored to tenant storage space1627. A UI 730 provides a user interface and an API 1632 provides anapplication programmer interface into system 1616 resident processes tousers and/or developers at user systems 1612. The tenant data and thesystem data may be stored in various databases, such as one or moreOracle™ databases.

Application platform 1618 includes an application setup mechanism 1638that supports application developers' creation and management ofapplications, which may be saved as metadata into tenant data storage1622 by save routines 1636 for execution by subscribers as one or moretenant process spaces 1604 managed by tenant management process space1610 for example. Invocations to such applications may be coded usingPL/SOQL 1634 that provides a programming language style interfaceextension to API 1632. Invocations to applications may be detected byone or more system processes, which manages retrieving applicationmetadata 1631 for the subscriber making the invocation and executing themetadata as an application in a virtual machine.

Each application server 1600 may be communicably coupled to databasesystems, e.g., having access to system data 1625 and tenant data 1623,via a different network connection. For example, one application server1600 ₁ might be coupled via the network 1614 (e.g., the Internet),another application server 1600 _(N-1) might be coupled via a directnetwork link, and another application server 1600 _(N) might be coupledby yet a different network connection. Transfer Control Protocol andInternet Protocol (TCP/IP) are typical protocols for communicatingbetween application servers 1600 and the database system. However, itwill be apparent to one skilled in the art that other transportprotocols may be used to optimize the system depending on the networkinterconnect used.

In certain embodiments, each application server 1600 is configured tohandle requests for any user associated with any organization that is atenant. Because it is desirable to be able to add and remove applicationservers from the server pool at any time for any reason, there ispreferably no server affinity for a user and/or organization to aspecific application server 1600. In one embodiment, therefore, aninterface system implementing a load balancing function (e.g., an F5Big-IP load balancer) is communicably coupled between the applicationservers 1600 and the user systems 1612 to distribute requests to theapplication servers 1600. In one embodiment, the load balancer uses aleast connections algorithm to route user requests to the applicationservers 1600. Other examples of load balancing algorithms, such as roundrobin and observed response time, also can be used. For example, incertain embodiments, three consecutive requests from the same user mayhit three different application servers 1600, and three requests fromdifferent users may hit the same application server 1600. In thismanner, system 1616 is multi-tenant, in which system 1616 handlesstorage of, and access to, different objects, data and applicationsacross disparate users and organizations.

As an example of storage, one tenant might be a company that employs asales force where each salesperson uses system 1616 to manage theirsales process. Thus, a user might maintain contact data, leads data,customer follow-up data, performance data, goals and progress data,etc., all applicable to that user's personal sales process (e.g., intenant data storage 1622). In an example of a MTS arrangement, since allof the data and the applications to access, view, modify, report,transmit, calculate, etc., can be maintained and accessed by a usersystem having nothing more than network access, the user can manage hisor her sales efforts and cycles from any of many different user systems.For example, if a salesperson is visiting a customer and the customerhas Internet access in their lobby, the salesperson can obtain criticalupdates as to that customer while waiting for the customer to arrive inthe lobby.

While each user's data might be separate from other users' dataregardless of the employers of each user, some data might beorganization-wide data shared or accessible by a plurality of users orall of the users for a given organization that is a tenant. Thus, theremight be some data structures managed by system 1616 that are allocatedat the tenant level while other data structures might be managed at theuser level. Because an MTS might support multiple tenants includingpossible competitors, the MTS may have security protocols that keepdata, applications, and application use separate. Also, because manytenants may opt for access to an MTS rather than maintain their ownsystem, redundancy, up-time, and backup are additional functions thatmay be implemented in the MTS. In addition to user-specific data andtenant specific data, system 1616 might also maintain system level datausable by multiple tenants or other data. Such system level data mightinclude industry reports, news, postings, and the like that are sharableamong tenants.

In certain embodiments, user systems 1612 (which may be client systems)communicate with application servers 1600 to request and updatesystem-level and tenant-level data from system 1616 that may requiresending one or more queries to tenant data storage 1622 and/or systemdata storage 1624. System 1616 (e.g., an application server 1600 insystem 1616) automatically generates one or more SQL statements (e.g.,one or more SQL queries) that are designed to access the desiredinformation. System data storage 1624 may generate query plans to accessthe requested data from the database.

Each database can generally be viewed as a collection of objects, suchas a set of logical tables, containing data fitted into predefinedcategories. A “table” is one representation of a data object, and may beused herein to simplify the conceptual description of objects and customobjects as described herein. It is understood that “table” and “object”may be used interchangeably herein. Each table generally contains one ormore data categories logically arranged as columns or fields in aviewable schema. Each row or record of a table contains an instance ofdata for each category defined by the fields. For example, a CRMdatabase may include a table that describes a customer with fields forbasic contact information such as name, address, phone number, faxnumber, etc. Another table might describe a purchase order, includingfields for information such as customer, product, sale price, date, etc.In some multi-tenant database systems, standard entity tables might beprovided for use by all tenants. For CRM database applications, suchstandard entities might include tables for Account, Contact, Lead, andOpportunity data, each containing pre-defined fields. It is understoodthat the word “entity” may also be used interchangeably herein with“object” and “table.”

In some multi-tenant database systems, tenants may be allowed to createand store custom objects, or they may be allowed to customize standardentities or objects, for example by creating custom fields for standardobjects, including custom index fields. In certain embodiments, forexample, all custom entity data rows are stored in a single multi-tenantphysical table, which may contain multiple logical tables perorganization. It is transparent to customers that their multiple“tables” are in fact stored in one large table or that their data may bestored in the same table as the data of other customers.

FIG. 17 illustrates a diagrammatic representation of a machine 1700 inthe exemplary form of a computer system, in accordance with oneembodiment, within which a set of instructions, for causing themachine/computer system 1700 to perform any one or more of themethodologies discussed herein, may be executed. In alternativeembodiments, the machine may be connected (e.g., networked) to othermachines in a Local Area Network (LAN), an intranet, an extranet, or thepublic Internet. The machine may operate in the capacity of a server ora client machine in a client-server network environment, as a peermachine in a peer-to-peer (or distributed) network environment, as aserver or series of servers within an on-demand service environment.Certain embodiments of the machine may be in the form of a personalcomputer (PC), a tablet PC, a set-top box (STB), a Personal DigitalAssistant (PDA), a cellular telephone, a web appliance, a server, anetwork router, switch or bridge, computing system, or any machinecapable of executing a set of instructions (sequential or otherwise)that specify actions to be taken by that machine. Further, while only asingle machine is illustrated, the term “machine” shall also be taken toinclude any collection of machines (e.g., computers) that individuallyor jointly execute a set (or multiple sets) of instructions to performany one or more of the methodologies discussed herein.

The exemplary computer system 1700 includes a processor 1702, a mainmemory 1704 (e.g., read-only memory (ROM), flash memory, dynamic randomaccess memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM(RDRAM), etc., static memory such as flash memory, static random accessmemory (SRAM), volatile but high-data rate RAM, etc.), and a secondarymemory 1718 (e.g., a persistent storage device including hard diskdrives and a persistent database and/or a multi-tenant databaseimplementation), which communicate with each other via a bus 1730. Mainmemory 1704 includes a blockchain services interface 1724 by which tointerface tenants and users of the host organization with availablesupported blockchains, public or private. Main memory 1704 also includesa blockchain consensus manager 1723 and a block validator 1725. Mainmemory 1704 and its sub-elements are operable in conjunction withprocessing logic 1726 and processor 1702 to perform the methodologiesdiscussed herein.

Processor 1702 represents one or more general-purpose processing devicessuch as a microprocessor, central processing unit, or the like. Moreparticularly, the processor 1702 may be a complex instruction setcomputing (CISC) microprocessor, reduced instruction set computing(RISC) microprocessor, very long instruction word (VLIW) microprocessor,processor implementing other instruction sets, or processorsimplementing a combination of instruction sets. Processor 1702 may alsobe one or more special-purpose processing devices such as an applicationspecific integrated circuit (ASIC), a field programmable gate array(FPGA), a digital signal processor (DSP), network processor, or thelike. Processor 1702 is configured to execute the processing logic 1726for performing the operations and functionality which is discussedherein.

The computer system 1700 may further include a network interface card1708. The computer system 1700 also may include a user interface 1710(such as a video display unit, a liquid crystal display, etc.), analphanumeric input device 1712 (e.g., a keyboard), a cursor controldevice 1714 (e.g., a mouse), and a signal generation device 1716 (e.g.,an integrated speaker). The computer system 1700 may further includeperipheral device 1736 (e.g., wireless or wired communication devices,memory devices, storage devices, audio processing devices, videoprocessing devices, etc.).

The secondary memory 1718 may include a non-transitory machine-readablestorage medium or a non-transitory computer readable storage medium or anon-transitory machine-accessible storage medium 1731 on which is storedone or more sets of instructions (e.g., software 1722) embodying any oneor more of the methodologies or functions described herein. The software1722 may also reside, completely or at least partially, within the mainmemory 1704 and/or within the processor 1702 during execution thereof bythe computer system 1700, the main memory 1704 and the processor 1702also constituting machine-readable storage media. The software 1722 mayfurther be transmitted or received over a network 1720 via the networkinterface card 1708.

None of the claims in the are intended to invoke paragraph six of 35U.S.C. § 115 unless the exact words “means for” are followed by aparticiple. While the subject matter disclosed herein has been describedby way of example and in terms of the specific embodiments, it is to beunderstood that the claimed embodiments are not limited to theexplicitly enumerated embodiments disclosed. To the contrary, thedisclosure is intended to cover various modifications and similararrangements as are apparent to those skilled in the art. Therefore, thescope of the appended claims are to be accorded the broadestinterpretation so as to encompass all such modifications and similararrangements. It is to be understood that the above description isintended to be illustrative, and not restrictive. Many other embodimentswill be apparent to those of skill in the art upon reading andunderstanding the above description. The scope of the disclosed subjectmatter is therefore to be determined in reference to the appendedclaims, along with the full scope of equivalents to which such claimsare entitled.

What is claimed is:
 1. A method, performed by a system of a hostorganization, the system having at least a processor and a memorytherein, wherein the method comprises: operating a blockchain interfaceto a blockchain on behalf of a plurality of tenants of the hostorganization, wherein each of the plurality of tenants are participatingnodes with the blockchain; receiving a login request from a user device;authenticating the user device with the host organization; receivinginput from the user device indicating a plurality of smart contractblocks; translating each of the smart contract blocks into a nativeprogramming language to form a smart contract to execute via theblockchain; and transacting the smart contract onto the blockchain. 2.The method of claim 1, further comprising: transmitting a flow designerGUI to the user device; and wherein receiving the input from the userdevice comprises receiving inputs via the flow designer GUI indicatinguser selections of the plurality of smart contract blocks with aplurality of flow sequence, flow conditions, flow triggers, and/or flowevent operations.
 3. The method of claim 1: wherein receiving the inputfrom the user device indicating the plurality of smart contract blockscomprises receiving an Apex input file programmed in Apex programminglanguage; wherein the method further comprises parsing a plurality ofApex defined smart contract blocks from the Apex input file; and whereintranslating each of the smart contract blocks comprises translating theplurality of parsed Apex defined smart contract blocks into the nativeprogramming language to form the smart contract to execute via theblockchain.
 4. The method of claim 1, wherein translating each of thesmart contract blocks into the native programming language to form asmart contract comprises translating each of the plurality of smartcontract blocks into a defined sequence of process operations for thesmart contract, a defined smart contract condition, a defined smartcontract trigger, and/or a defined smart contract event.
 5. The methodof claim 1, wherein transacting the smart contract onto the blockchaincomprises: writing the smart contract into the blockchain as metadatavia a blockchain services interface of the host organization; andwherein the smart contract executes via the blockchain for one or moretransactions occurring on the blockchain.
 6. The method of claim 1,further comprising: extracting an event listener from the input receivedfrom the user, wherein the event listener monitors the blockchaintransactions for defined events having a corresponding smart contractcondition or smart contract trigger within the smart contract transactedonto the blockchain; and executing the event listener separate from theblockchain, wherein the event listener executes within the hostorganization and triggers a pre-programmed action within the hostorganization upon occurrence of the event within a transaction on theblockchain.
 7. The method of claim 6: wherein the event listenerexecutes within a Customer Relationship Management (CRM) platform of thehost organization on behalf of a tenant of the host organization whichis a participating party to the smart contract executing on theblockchain; and wherein executing the event comprises one of: halting apayment via the CRM system pursuant to a violation of terms orconditions defined by the smart contract executing within the blockchainor authorizing payment via the CRM system pursuant to fulfillment of allterms and conditions defined by the smart contract executing within theblockchain.
 8. The method of claim 1, wherein translating each of thesmart contract blocks into a native programming language to form a smartcontract to execute via the blockchain, comprises: translating each ofthe smart contract blocks into an Ethereum compliant Solidityprogramming language; wherein the host organization operates aparticipating node on an Ethereum blockchain via a blockchain servicesinterface of the host organization; and wherein transacting the smartcontract onto the blockchain comprises transacting the smart contractonto the Ethereum blockchain via the participating node for executionvia the Ethereum blockchain.
 9. The method of claim 1, whereintranslating each of the smart contract blocks into a native programminglanguage to form a smart contract to execute via the blockchain,comprises: translating each of the smart contract blocks into aHyperledger compliant Go programming language; wherein the hostorganization operates a participating node on a Hyperledger blockchainvia a blockchain services interface of the host organization; andwherein transacting the smart contract onto the blockchain comprisestransacting the smart contract onto the Hyperledger blockchain via theparticipating node for execution via the Hyperledger blockchain.
 10. Themethod of claim 1, wherein receiving the input from the user deviceindicating a plurality of smart contract blocks comprises: transmittinga flow designer GUI from a GUI manager of the host organization to theuser device for display at the user device; and receiving mouse movementevents at the flow designer GUI displayed to the user device indicatingdrag and drop selections and sequencing of available smart contractconditions, triggers, and events available via the flow designer GUI.11. Non-transitory computer readable storage media having instructionsstored thereon that, when executed by a system of a host organizationhaving at least a processor and a memory therein, the instructions causethe system to perform the following operations: operating a blockchaininterface to a blockchain on behalf of a plurality of tenants of thehost organization, wherein each of the plurality of tenants areparticipating nodes with the blockchain; receiving a login request froma user device; authenticating the user device with the hostorganization; receiving input from the user device indicating aplurality of smart contract blocks; translating each of the smartcontract blocks into a native programming language to form a smartcontract to execute via the blockchain; and transacting the smartcontract onto the blockchain.
 15. The non-transitory computer readablestorage media of claim 11, wherein the instructions cause the system toperform operations further comprising: transmitting a flow designer GUIto the user device; and wherein receiving the input from the user devicecomprises receiving inputs via the flow designer GUI indicating userselections of the plurality of smart contract blocks with a plurality offlow sequence, flow conditions, flow triggers, and/or flow eventoperations.
 13. The non-transitory computer readable storage media ofclaim 11: wherein receiving the input from the user device indicatingthe plurality of smart contract blocks comprises receiving an Apex inputfile programmed in Apex programming language; wherein the method furthercomprises parsing a plurality of Apex defined smart contract blocks fromthe Apex input file; and wherein translating each of the smart contractblocks comprises translating the plurality of parsed Apex defined smartcontract blocks into the native programming language to form the smartcontract to execute via the blockchain.
 14. The non-transitory computerreadable storage media of claim 11, wherein translating each of thesmart contract blocks into the native programming language to form asmart contract comprises translating each of the plurality of smartcontract blocks into a defined sequence of process operations for thesmart contract, a defined smart contract condition, a defined smartcontract trigger, and/or a defined smart contract event.
 15. Thenon-transitory computer readable storage media of claim 11, whereintransacting the smart contract onto the blockchain comprises: writingthe smart contract into the blockchain as metadata via a blockchainservices interface of the host organization; and wherein the smartcontract executes via the blockchain for one or more transactionsoccurring on the blockchain.
 16. The non-transitory computer readablestorage media of claim 11, wherein the instructions cause the system toperform operations further comprising: extracting an event listener fromthe input received from the user, wherein the event listener monitorsthe blockchain transactions for defined events having a correspondingsmart contract condition or smart contract trigger within the smartcontract transacted onto the blockchain; and executing the eventlistener separate from the blockchain, wherein the event listenerexecutes within the host organization and triggers a pre-programmedaction within the host organization upon occurrence of the event withina transaction on the blockchain.
 17. The non-transitory computerreadable storage media of claim 11: wherein the event listener executeswithin a Customer Relationship Management (CRM) platform of the hostorganization on behalf of a tenant of the host organization which is aparticipating party to the smart contract executing on the blockchain;and wherein executing the event comprises one of: halting a payment viathe CRM system pursuant to a violation of terms or conditions defined bythe smart contract executing within the blockchain or authorizingpayment via the CRM system pursuant to fulfillment of all terms andconditions defined by the smart contract executing within theblockchain.
 18. A system to execute at a host organization, wherein thesystem comprises: a memory to store instructions; a processor to executeinstructions; wherein the processor is to execute a blockchain interfaceto a blockchain on behalf of a plurality of tenants of the hostorganization, wherein each of the plurality of tenants are participatingnodes with the blockchain; a receive interface to receive a loginrequest from a user device; an authenticator to authenticate the userdevice with the host organization; the receive interface to furtherreceive input from the user device indicating a plurality of smartcontract blocks; a translator to translate each of the smart contractblocks into a native programming language to form a smart contract toexecute via the blockchain; and a blockchain services interface totransact the smart contract onto the blockchain.
 19. The system of claim18, further comprising: a GUI manager to transmit a flow designer GUI tothe user device; and wherein the receive interface is to receive inputsvia the flow designer GUI indicating user selections of the plurality ofsmart contract blocks with a plurality of flow sequence, flowconditions, flow triggers, and/or flow event operations.
 20. The systemof claim 18: wherein the receive interface is to receive inputs from theuser device indicating the plurality of smart contract blocks comprisesreceiving an Apex input file programmed in Apex programming language;wherein the system further comprises an Apex block translator to parse aplurality of Apex defined smart contract blocks from the Apex inputfile; and wherein the translator is to translate the plurality of parsedApex defined smart contract blocks into the native programming languageto form the smart contract to execute via the blockchain.
 21. The systemof claim 18: wherein the translator is to translate each of theplurality of smart contract blocks into a defined sequence of processoperations for the smart contract, a defined smart contract condition, adefined smart contract trigger, and/or a defined smart contract event.22. The system of claim 18, wherein the blockchain services interface tois transact the smart contract by writing the smart contract into theblockchain as metadata via a blockchain services interface of the hostorganization; and wherein the smart contract executes via the blockchainfor one or more transactions occurring on the blockchain.
 23. The systemof claim 18, further comprising: an apex listener to extract an eventlistener from the input received from the user, wherein the eventlistener is to monitor the blockchain transactions for defined eventshaving a corresponding smart contract condition or smart contracttrigger within the smart contract transacted onto the blockchain; andwherein the host organization is to execute the event listener separatefrom the blockchain and trigger a pre-programmed action within the hostorganization upon occurrence of the event within a transaction on theblockchain.